When I am teaching CSM and CSPO classes I frequently get questions from students who have trouble understanding how work flows from the release level down through product backlog items like User Stories on down to the task level. I do cover this in class but for some, it is not so easy to see.
In hopes of resolving this, I asked Judy Neher, a fellow Certified Scrum Trainer, to help me work through a metaphor that I hope will provide clarity on how we take work from Releases to User Stories to Tasks, how they tie back to strategy and vision and how Epics and Themes fit in as well.
If you'd like to reach out to Judy with follow up questions, here is her contact info:
This is a great metaphor. I would suggest that the problem however is not so much that some people don't get how to go from the big picture to the tasks, but that the common Agile model of requirements decomposition is missing a key component and that it forces people to bridge the gap. Unfortunately, even when people do bridge the gap, many do it differently and this causes another problem.
What's missing? A 16 year old concept put forth in Software by Numbers: Low-Risk, High-Return Development. They called the term Minimum Marketable Feature (MMF). It's the smallest releasable item for which value can be realized from a business perspective. It's not an epic (epics are larger than this) and it's not usually a feature (features often can't be released on their own) and it's not even the smallest releable thing because sometimes that doesn't make sense. For example, coffee is releasable on its own, but "releasing" it with dessert made more sense.
Note that SAFe redefined the MMF - and what they call the MMF has virtually nothing to do with what the intent of the MMF is.
When I was with Net Objectives, we started using the MMF concept in 2005 and I would attribute a good 50% of our success to it. In fact, i know some companies who transformed their company on their own just with this concept.
After a few months of using this, however, we found a challenge with the name of the MMF was that IT companies said they didn't have products and therefore didn't market. We eventually renamed the term to be Minimum Business Increment as that was more intention revealing and works everywhere.
Here's an article on the MBI https://portal.netobjectives.com/pages/books/going-beyond-lean-and-agile/the-minimum-business-increment/
Note how the concept of the MBI ties the big picture (meal / initiative) to the small task (putting cream in coffee). The meal is the initiative. The courses are the MBIs. An MBI may be composed of one or more items (e.g., coffee and dessert), each of these may have tasks (e.g., coffee= coffee itself, cream, sugar).
When I look back on my 20 years experience with Agile and see what cauess a lot of confusion and makes alignment more difficult than it needs to be I attribute the lack of the MBI to be the main cause. Note that an MBI (which is about building something we know to be of value, just need to figure out the details), is quite different from an MVP. That is, with the Italian dinner we have the whole in mind and decompose it. If we were trying to create a new kind of dinner we might start with an appetiser and see how to go from there.
I think i'm going to use this metaphor :) will give attribution. It's a nice concept.