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, lunivore 
Reblogged this on sebsonconferences.
Hi Liz,
In order to start using BDD and improve both my communication and dev skills
As a software developer
I am reading articles, books and listening to talks about BDD
I did read this article of yours before and some parts were not completely clear to me.
I was thinking about the ‘how to’ or the ‘where’. I’ll explain.
Today, I was watching your talk on Youtube ’10 years of Doing Behaviour-Driven Development All Wrong (part2)’ and the slide about the Fractal beauty reminded me of this article.
Fractal beauty slide tells about:
Vision -> Goals -> Capabilities -> Features -> Stories -> Scenarios -> Code
I reviewed the slide and this article, and I noticed that you don’t talk much about the scenarios here. So I was wondering where do I keep all the things that makes up the Fractal beauty.
Then I found this article ( http://blog.mattwynne.net/2010/10/22/features-user-stories/ ) and realized that if you are using Cucumber the stories simply vanish, at least from the codebase.
This is quite long already and I have just one — or two– small questions. How do you organize your projects? Which things (from Vision to Scenarios) do you keep and where? And how do they evolve?
Thank you for your time!
Hi Jorge, sorry it took a while to get to this due to being abroad.
The vision, goals and capabilities tend not to change for a project, and there won’t be many (typically between 5 and 30 depending on the size of project). Normally they’re either on a wall, or they’re parents of story-children in an electronic storage system like LeanKit, Rally or Jira. I prefer the wall obviously. I see occasional new capabilities being added at the beginning of the project, when people are still thinking about what they’ll need to achieve. Occasionally new stakeholders and therefore capabilities will be discovered when putting code live, too, but on the whole there’s little change here. This is why I think this level make a great tool for planning.
Features often have a 1-to-1 mapping with capabilities, but they’re the concrete implementation of the capabilities, which means they’re usually code, therefore stored in git.
Stories are just a way of slicing up features to get feedback on them more quickly and to help create trust with stakeholders. They’re transient, and I don’t normally store them. The story template (either “As a… I want… so that…” or “In order to… I want… so that”) is just another way of phrasing the goals, capabilities or features, depending on what level you target. That’s the kind of thing that people often put at the top of their Cucumber feature files, but if you’ve captured the capabilities associated those with different stakeholder’s goals then you’ve already got everything that’s in those templates anyway. You could store your stories in an electronic tool if you wanted to keep a record, and some people also like to keep the scenarios there too, before they move them to Cucumber (if they do automate them; not everything needs to be automated at that level).
You might find more information useful to you in the Capability Red category.
This was helpful. Thank you!
enjoyed your perspective and agree with it. I am a big advocate of describing assets as real world value [and recognizable] capabilities. I also tend to focus on what the value is coming from the capability [context sensitive ‘quarks’ of information 🙂 ]
Thank you.