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 WebsiteYou 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 needsNote 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 customerIn real life there would likely be similar stories, such as finding a branch by hours of operation, or by zip code.
find a branch that is close to a specific address
so that I can minimize travel
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.
Subscribe to the RSS feed
8 comments:
to add to the list of rfeferences: i gave a talk about the same requirements management approach at Agile Eastern Europe. the basic comcept is the same, but the approach I had was to prove that other Requirements management approaches do not scale.
You can see the blog post with a video of the talk, here: http://bit.ly/c6JNX5
How about the approach with no epics? From Goals, straight to Features, Stories and Tasks?
Vasco,
Interesting video.
I like your definition of scaling on a project "A Software Development Process scales if (and only if) the work it takes to manage a project increases at a slower pace than the amount of work being managed!"
I also agree with your comment at the end of the video about not committing to the story (i.e. implementation), but instead committing at the level of the Feature or Epic.
In the way I laid out the hierarchy, commitment is to the Goal / Outcome, meaning that the team has freedom to make changes even at the level of the Epic. In some cases you may want to limit this flexibility to a lower level, but all things being equal, I prefer to loosen the implementation constraints as much as possible.
So thanks for linking to your video, I really enjoyed it.
Olga,
I agree with you. It is perfectly valid to go directly from Goals to Features, leaving out the Epics.
Epics are the least important level of the hierarchy as defined in this example.
The story level has to be there, as it defines the day to day work in an iteration. The feature level provides the conceptual level where Product Owners should concentrate (i.e. the team has great latitude on the stories). The goal / outcome provides the success measure, and the vision provides the context.
Where do use cases fit in this hierarchy?
Lance,
I purposely left Use Cases out of the taxonomy because they are done in a variety of ways. Some teams benefit from using traditional, and yes fairly heavyweight, Use Case and other teams benefit from lightweight Essential Use Cases.
For Essential Use Cases, they apply quite well at the Story Level. For heavier weight Use Cases, I would still prefer them to be at the Story Level, and I would prefer to have them created only for the highest priority Product Backlog items, in close proximity to when the Story will be worked on.
How do you know you have captured all the features/stories in this decomposition?
David,
I read a few pages of your recent book (http://www.amazon.com/Cascade-David-Wright/dp/1435718534), which looks very practical, so after reading my response I would like to hear your input.
From my perspective, your question gets to the heart of how a good requirements approach can be much better than a heavyweight one.
In a heavyweight approach, we spend countless hours and months attempting to collect granular requirements, in the form, “The system shall…”. We review frequently to make sure we have captured everything, and thus delay the start of the project for many months.
Capturing all of the stories, at least upfront, is not important (IMO).
In the example I gave, if we know that the outcome desired for the “As a customer find a branch location” feature is to increase retention, especially for small business customers (per the vision), then we will focus on creating a search that is most applicable to small business customers, and we may not know what the best search mechanisms will be until we start digging in.
Perhaps we thought that the highest priority would be a search by distance from a specific address. But hen we look at the data we realize that only a small number of branches offer services customized for a small business.
So, searching by address won’t be all that helpful for a small business owner interested in purchasing BOP (business owner’s policy) Insurance because only a handful of branches have the right expertise anyway.
We make late changes to our feature decomposition, and decide that we will first deliver a search by zip code (easier then address) then we will quickly follow up with a search by zip code + services to make direct progress on our vision of being the eBanking provider of choice for small business customers.
We won’t necessarily know the ideal decomposition until we start, so in a sense we don’t know, nor do we care, that we have captured everything at the story level.
Now, jumping up to the feature level, by keeping the features brief, and not getting lost in the weeds of “the system shall…”, we can more easily review, and ensure that we are not missing anything major, but if we do miss a few things early, and address them later, is this really a problem?
The higher up the taxonomy, the less we need to manage, and thus the easier it is for us to identify in advance what we need. At the bottom of the taxonomy, we shouldn’t sweat the small stuff, so, if we miss a few things early on, it is not a problem.
I would like to hear your input because everyone has a different base of experience to build on.
Post a Comment