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.

Questions?