Story Decomposition is one of 3 related techniques which can be confused if we are not careful. The other two are Story Elaboration and Backlog Refinement.
Story Decomposition is used to represent the requirements for a solution at the appropriate level of detail and are aligned to desired outcomes.
Agile Extension to the BABOK® Guide – section 7.18
The quote above gives the purpose of Story Decomposition from the Agile Extension. When I first read this, I wasn’t exactly sure what it meant. It remained confusing until I understood where this technique differs from Story Elaboration and Backlog Refinement.
Story Decomposition is well suited for the Initiative Horizon, but continues in Delivery. That is because it involves basically breaking down product to feature to stories. In other words, stories may be decomposed at one level for the Initiative Horizon, but a different level for the Delivery Horizon. At either level, traceability to desired outcomes must be enforced.
Those features and stories can all be traced back to the desired outcomes. So when I think of Story Decomposition, I think more like a Work Breakdown Structure in an Epic/Feature and Story format.
Part of my confusion is that I had heard another term, Backlog Grooming – encompassing all 3 techniques – which is not mentioned in the Extension. All of which were used loosely and interchangeably on prior projects.
The Agile Extension is more rigorous than that.
Elements
Story Decomposition begins with Solution Goals and why the initiative is happening to begin with. Then those goals are broken into Minimally Marketable Features or Components. Those Components become a set of User Stories, Job Stories or Use Cases. And these have acceptance criteria.
When we’ve gotten to this level, that is what Story Decomposition is about.
Description
Breaking down the problem into small pieces is one of the central elements of many Agile frameworks. Without this process, much of the functioning of Agile would not be possible. So Story Decomposition is very important.
It is finished when all Minimal Marketable Features are written with full acceptance criteria.
The context is Requirements Management and the audience is Internal Team.
You may be asking “Why is Story Decomposition considered Requirements Management instead of Product Management or Refinement?”
Product Management and Refinement has more to do with the overall vision of the solution, and the prioritization of features. You can see it with MVP, Product Roadmap, Purpose Alignment Model, Real Options and Kano Analysis. These relate to the features or higher.
On the other hand, Requirements Management has to do with managing the details that define those features. You can see it with Story Decomposition, Story Elaboration, Job Stories, Behavior Driven Development, Relative Estimation, Spikes, Story Mapping and User Stories. These are the working items that will be directly developed by the team.
Usage Considerations
Story Decomposition allows the team to retain the big picture focus, while defining the Minimal Marketable Features or Epics.
However, do not try this with a software architecture.
And it’s a good idea to keep at a higher level until you’re really ready to prepare things for development.
You must log in to post a comment.