In agile when we talk about requirements, we often talk about epics, features and user stories.
But, do we really know how these different levels of requirements fit together, and how they relate to vision, goals and outcomes?
This post provides a simple example of what a requirements breakdown can look like. This is nothing new and is similar to a functional breakdown structure, or product oriented work breakdown structure that has been used since I started my career over 25 years ago.
An Example
It Starts with a Vision
At the top of the hierarchy is a vision. The vision is broad in scope and addressing it can take many years and many projects. In this example, our vision is:
Be the eBanking Provider of choice for small business customers
Goals, or if you like, Outcomes
To address our vision we have goals, or if you like outcomes (more below). In this example, the goal / outcome is:
Increase retention on eBanking Website
You could make this more concrete, and thus turn it into an outcome, by including a measurement, stating something like:
Increase retention of small business eBanking customers by 20% as measured by…
Epics, Cohesive, Large Chunks of Business Value
Below the goals we have epics, which are large grained chunks of business value, that, by definition, will take more than on iteration to complete. In fact, epics can be so large that they may take several releases to complete. In this example, the epic is:
Add a Customer Center for self service for common needs
Note that even though this is an epic, you could still write it in user story format, perhaps like this:
As a customer
I want to handle my self service needs online
So that I can address them 24 by 7 by 365 without leaving the house or making a call
Features, Cohesive, but Smaller Chunks of Business Value
At the next level down are features, which in this model, are cohesive chunks that address a particular need. In this model, features are smaller than epics and it often possible to complete a feature in a single release or even in one iteration. In this case our feature is..
As a customer find a branch location
The Stories
At the lowest level of the hierarchy are the actual stories. In this example the stories were split from the “find a branch” feature. Here is one.
As a customer
find a branch that is close to a specific address
so that I can minimize travel
In real life there would likely be similar stories, such as finding a branch by hours of operation, or by zip code.
In Closing
There are number of variations on decomposition for requirements, and although this example is not comprehensive, I think a picture is worth a 1,000 words.
You can also check out other blogs that cover similar topics. Dean Leffingwell covered this in a comprehensive white paper you can get from his site.
Drew Jemilo’s blog specifies a very similar take. I would have never have found it if I hadn’t talked to him a couple of months back, so check it out at his blog.
Enjoy.
