Brief:
A capabilities are something that a stakeholder has asked for. Because a stakeholder has asked for they see value in it from their perspective. We call anything the stakeholder asks for as something of value and something they desire. Stakeholders can be considered as observers of the systems, sometimes users and they see things from the view point of capabilities or collections of behavior that they want the system to provide.
Word Confusion:
Sometime we use the word feature, big story, enhancements, desires, big requirements or major feature to describe these things. However, this often leads to a confusion in the use of words and does not support the analysis. To keep things clear and make the point better with a clean WBS we will focus on primary decomposition pattern of Capability – Story – Task. The picture will become more involved and complicated than that but, we will focus on the simplest pattern to solve each step of evolving difficulty in managing and analyzing a complex problem. We will answer the questions of a more complicated analysis pattern in an upcoming post on the Analysis and an Agility Enable WBS.
We will break capabilities by the following pattern: Product => Capabilities => Stories => Tasks (more on this in another post)
What is a capability?
Typically, open ended and fuzzy in scope. A system is made up of behavior that can be broken down into capabilities from the view point of the observer of that system. As an analyst / Product Owner, The point of view we care about is that of the stakeholders.
Capabilities are the things we talk about what our stakeholders, and we talk about them in the stakeholder’s language. Strictly speaking, capabilities are seldom of concern to the development team, as the developers will be working on stories, which we’ll discuss later in this chapter. Capabilities far too often too big, hard to validate chucks of work, so it is not something we want to feed our team directly as an item of work. The reason is simple, large chunks or difficult to validate chunks of work lead to elongated feedback cycles and this is what got us into trouble in the first place.
Why?
Our development is being done to acquire those capabilities for the stakeholders, and therefore we must be able to talk about capabilities with our stakeholders. Capabilities are the language the stakeholders and thinking in and it’s is what they will use to understand the product we have built.
