Requirement is a nebulous term. It can mean something large like a strategy, to smaller items like features, user stories, or tasks. People often throw around the word requirement without a strong sense of the type of requirement it is or the level it belongs. It is important for clarity and common understanding across organizations and teams. Otherwise, it can be quite confusing as to which level people are discussing.
To gain this common understand of the various levels of requirement, I recommend starting by establishing a requirements tree. It is a structure that represents the relative hierarchy amongst various requirements elements within your enterprise. It makes it clear how requirements levels are connected. For example, a feature is a requirements element that is at the larger than a user story, so I would expect to find multiple children (aka, user stories) to the build a feature. Think of it as your requirements lineage.
What are advantages of creating a requirements tree? First, it ensures that requirements elements at the lower level (aka., the children) are aligned to higher level and presumably high value requirements elements. This ensures that you are putting all of your company’s effort on the highest value work. Second, it helps you determine if there are random requirements that made their way in through a back door. Third, the requirements tree provides context of the level of requirement being discussed and traceability in the hierarchy.
What are the various requirements elements and hierarchy? There is no industry standard group in either and they can vary from enterprise to enterprise. The key is to establish yours. I like to start with corporate strategy and end with tasks as illustrated in the figure.
Once you establish the levels of your requirements tree, it is important to craft a definition to describe each level. Using the requirement levels from the figure, here is how I describe each level. A strategy sets direction for the enterprise. An idea is a high customer value and outcome-based opportunity. An increment is an end-to-end slice of the idea to provide value and validate of the idea. An epic is a function or feature. A user story is a requirement that fits into a sprint of a week or two and has one persona. A task is a very small unit of work that incrementally builds the user story.
In addition, when you have the requirements tree and definitions of each level, you can align roles of who should be working on those levels with expectations and outcomes of each level.
You may notice that instead of putting the strategy on top, I place it on the bottom. I do this to represent the strategy as the trunk of the tree as this should provide guidance for how the smaller requirements elements (e.g., ideas, increments, epics, user stories, and tasks) should grow. While your strategy may adapt over time based on customer feedback and the changing marketplace, it should guide the type of work you may consider working on.
The key to your requirements tree is for you to establish one that makes sense for the type of work you do. For example, if you only have one division in your company, then a division strategy isn’t necessary. You may also work with business requirements so place them in the right level for your tree. Those that may consider creating a requirements tree are a combination of executives, portfolio, product owners, and team members. Once crafted, it should be shared with everyone for a common understanding and a way to validate that the work at the team level is aligned with the highest value work.
Note: For more information on the Requirements Tree, read Chapter 15 of the book "The Agile Enterprise".
Requirements are not always linearly decomposable. So some requirements wont' fit easily under a particular traversal of a tree.
ReplyDeleteOne might also need to consider that some requirements have dependencies on other items in other trees.
So, in fact, the requirements tree then actually becomes more like a roadmap, do this first, then that, but with some idea of how the different ideas/features/items are related.
Yes, it should visually show this challenge (some requirements have dependencies on other items in other trees.). I've used this to help with understanding if we need more cross-functional teams or dependencies across teams.
DeleteYes if value and dependencies are appropriately indicated (do this first, then that, but with some idea of how the different ideas/features/items are related.)
Thanks for sharing your thoughts!
I had a question on how is this different from WBS. Here is my answer: They are really wholly different things.
ReplyDeleteFirst, most WBS is specific to either idea or increment on down and don't connect direct to strategy.
Second, Requirements Tree ensures that the connected work is based on the highest value work at each level. I've worked with WBS for years and there is often no associated value at each level. So you end up doing all of the tasks at the next level when the highest value may be all you need.
Third, you align who works at each level and with what tools (e.g., at an idea level, a PM/PO might use a lean canvas, while at a user story level, the PO might use the user/action/reason structure). The WBS offers no such guidance and each level is often the same.