By Liz Keogh
Every project worth doing has a vision, and someone who’s championed that vision and fought for the budget. That person is the primary stakeholder. (This person is the real product owner; anyone else is just a proxy with a title.)
In order to achieve the vision, a bunch of other stakeholders have goals which have to be met. For instance:
- The moderator of the site wants to stop bots spamming the site.
- The architect wants the system to be maintainable and extensible.
- The users want to know how to use the system.
These goals are tied in with the stakeholder’s roles. They don’t change from project to project, though they might change from job to job, or when the stakeholder changes roles internally.
Within a project, we deliver the stakeholder’s goals by providing people and the system with different capabilities. The capabilities show us how we will achieve the goals within the scope of a particular project, but aren’t concrete; it still doesn’t matter how we achieve the capabilities. The word “capability” means to be able to do something really well.
- The system will be able to tell whether users are humans or bots.
- Developers will be able to replace any part of the system easily.
- Users will be able to read documentation for each new screen.
Often we end up jumping straight from the goals to the features which implement the capabilities. I think it’s worth backtracking to remember what capability we’re delivering, because it helps us work out if there’s any other way to implement it.
- We’re creating this captcha box because we need to tell if humans are users or bots. Or we could just make them sign in via their Twitter account…
- We’re adding this adapter because we want to be able to replace the persistence layer if we need to. Or we could just use microservices and replace the whole thing…
- We’re writing documentation in the week before we go live. Or we could just generate it from the blurb in the automated scenarios…
By chunking up from the features to the capabilities, we can give ourselves more options. Options have value!
But chunking down from goals to capabilities is also useful. The goals for a stakeholder’s role don’t tend to change, but neither do the capabilities for the project, which makes them nice-sized chunks for planning purposes.
Features, which implement the capabilities, change all the time, especially if the capabilities are new. And stories are just a slice through a feature to get quick feedback on whether we’re delivering the capability or not (or understanding it well, or not!).
Be careful with the word epic, which I’ve found tends to refer indiscriminately to goals, capabilities, features or just slices through features which are a bit too big to get feedback on (big stories). The Odyssey is an epic. What you have is something different.
Liz Keogh is a Lean / Agile consultant.
Article source: http://www.pmhut.com/goals-vs-capabilities
Powered by Facebook Comments