Breaking Down a Plan

Sprint to Roadmap, Roadmap to Sprint (click to enlarge)

In my last post, we saw how we can break down an enterprise strategic plan into more granular levels of detail: the roadmap to the project to the release to the Sprint. At higher levels, we have less detail. Remember that Lean principles support the management practices of adaptive, feedback-based planning and just-in-time elaboration of detail.

As we break down our planning to greater levels of detail, we also need to break down our requirements specifications. You’re likely familiar with the Story and Verification Condition formats, which provide enough granular detail to define a Sprint’s tasks. However, in longer term strategic planning, such detail is waste. Why spend the resources to define detail which will likely change or may never be used?

As we plan at the highest strategic level and then drill down to projects, releases, and Sprints, we add more and more detail. Much like the work breakdown structure (WBS) in traditional project planning, we can break down our requirements to additional levels of detail.

Mapping the Plan to the Requirements Breakdown Structure

Since a picture is worth a thousand words, let’s let an image show the breakdown of requirements. The following is inspired by Dean Leffingwell’s work (see his blog post), discussion groups, and my own client work.

An Agile Requirements Breakdown Structure

Defining Requirements Levels

At the roadmap and project levels, planning is more structured. The plans are still reviewed and adapted, but less frequently than at the release and Sprint levels. Let’s take a closer look at definitions and examples.

The Initiative

One or more initiatives make up a roadmap and is the result of the strategic planning process. It delivers the capabilities to support the product strategy. Note that Scrum uses the term “Product” though many companies use the term “application.”

Example: Add paid subscriptions to the current free subscription model.

Epics

Initiatives are broken down into Epics to deliver a project. Epics are high level, abstracted requirements which deliver a portion of the initiative. One or more make up a project.

Example: Attract Premium subscribers by offering new, more desirable ways to receive Premium subscriber content.

Epics are typically defined in the project charter and support the business case.

Features

Epics are broken down into Features to deliver a release. Features provide the bridge between the business value and the end user value.

Example: Offer iPhone access so that the business can sell premium memberships to more iPhone users BECAUSE Premium subscribers can access their content on-the-go.

Both business value and end user value can be measured through quantitative and qualitative metrics. For example, the business value metric may be Sell 5,000 premium memberships in the first three months. The end user value metric may be Premium subscribers access their premium content one or more times per day.

Features can be estimated, often in Story points. They can also be tested through high level user acceptance tests.

Stories

Features are broken down into Stories to deliver a Sprint. The User Story specifies who, what, and why from the end user’s perspective, but not how. Because it does not tell how, it opens a conversation with the team about how the functionality can best be implemented, leveraging the team’s collective expertise.

Example: As a Premium subscriber and iPhone user, my subscription preferences apply to any interface I am using so that I only need to update them in one place.

Stories can be estimated, often in Story points. They can also be tested through verification conditions, which specify both the tests and the business logic (see Test Driven Development).

But Is It Agile?

Requirements decomposition has existed since the early days of Waterfall, but is it Agile? The answer is yes for two reasons. First, we follow Lean principles and avoid waste by drilling down into further levels of detail only when needed. We also drill down as late as possible (often know as the last responsible moment, or LRM) in order to leverage the latest available information. Second, we more frequently review and adapt at all levels in order to be more responsive to ambiguity and changing market conditions.

In my next blog post, I’ll take a look at Agile metrics.