Why you might struggle with Progressive Elaboration
Progressive Elaboration is the process of breaking Epics down into User Stories and defining details of those stories over time as the stories move through release planning and get closer and closer to being added to a Sprint. I’ve been exploring why some organizations struggle to put this into practice.
Context: I often work with largish organizations making commitments 2 to 4 months out. They use Scrum, stable teams, stable velocity and some amount of Epic/Feature/Story decomposition to make these commitments. Agile can help them be predictable. Whenever I begin working with these Product Owners and Program Managers I explain the need to quickly identify all the stories for the release (so that we could create or verify a release plan) yet also get 2-3 sprints worth of backlog ready for the teams because they are going to start sprinting soon. Sometimes this works like a charm. Other times teams have difficulty getting into the progressive elaboration approach. They can’t get beyond defining all the details for all the stories for an Epic in one pass.
When people think about defining requirements, they often have in mind planning a release and/or reducing misunderstanding. One’s primary purpose influences how fast or slow they go and to what level of detail they go:
Theory of Constraints Evaporating Cloud for Defining Requirements
So it seems that a compromise has to be made — to strike a balance between going fast and going slow, between writing more or writing less, between planning a release quickly or reducing misunderstanding for development.
There are some hidden assumptions underlying this thinking:
- It is more efficient to completely analyze any feature in just one step.
- We can’t plan a release without all the details.
On the contrary, we can plan a release with just a list of user stories. Planning a release with a list of features and user stories is a completely separate need than “have all the detail needed to develop and test”. The former is needed early on, and the later is needed much later. This time dimension is often overlooked.
Further, it’s not more efficient to completely analyze any feature in just one step if some people needed to do the analysis aren’t available when you want them involved. (For example, they may be fully allocated to wrapping up a prior release.) Even if it could be proven most efficient to look at a feature just once, with lean thinking we are less concerned about the efficiency of individual workers and are far more interested in the smooth flow of work. Local optimization sub-optimizes the whole. We get more value by keeping the valuable work flowing than we would by controlling costs. In this case, the work is the work of planning a release and decomposing features into stories and (eventually) coming up with the details for development just in time. If we can quickly come up with a list of user stories for the release plan, we keep the (program) management work flowing. The work of management in this case is ensuring that we can complete the release on time; and doing stakeholder management, risk management, and scope management if not. If we can’t come up with a list of all the stories for the release, then the work of management is blocked.
Now we can decouple these 2 things: release planning versus getting the details for development. We can redefine the problem and draw a new picture:
| Objective | Purpose | Prerequisite |
|---|---|---|
| Plan the release schedule | <— identify stories quickly | <— write less now |
| Plan sprints later | <— define gory detail JIT | <— write more later |
When I say “identify stories quickly”, I’m usually just talking about the story titles, 1 liners. When I say “write less now”, I also mean analyze less now. We need to analyze just enough to come up with a list of what the likely candidate user stories might be.
When I say “write more later”, I also mean to analyze more later. For that, consider the lead time. In the context that I operate (see above), my advice is to have 2 or 3 sprints worth of work ready. What “ready” means and how much detail is needed depends on the organization. Notice that “later” might just be 1 day later, but it’s still later than “now”.
With that said, can your Product Owner Team “now” identify the (likely) stories for the remaining features before coming up with the full details for any of them? Seems to me that the BA or PO paired up with someone technical should be able to look at the features on the wish list and come up with 1 to 5 user stories for each. Should be able to do that in a day or less.
P.s. If anyone cares, this approach of resolving a seeming conflict is from the Theory of Constraints and is known as the Evaporating Cloud Method.