Scaling Scrum With Epics

Scrum is an incredibly effective project management tool and has great success within small teams and large companies alike. As organizations move from one or two teams using Scrum to adopting an more enterprise-wide implementation, typical questions occur. One such question goes like this:

How does a Project Manager or Product Owner coordinate work across multiple Scrum teams?

There is a prescribed set of practices and techniques we can bring to bear to make scaling Scrum easier and more formulaic to answer this question.

Don’t Get Caught up on “Product”

The more I work with Scrum across the enterprise, the more I loath the word “product” in the Scrum vernacular. The Product Backlog is an essential part of Scrum and other Agile techniques. Although we use the term product, any significant internal system, strategic initiative, or product needs a roadmap and backlog. Since the word product elicits particular pre-conceived ideas , it is important to find a word that can be used in its place. Some people suggest Epic as a reasonable term and I have found great success with it.

Some possible Epics include:

• An internal resume tracking system
• A sales initiative to capture a particular share of a given market
• Moving to another platform for your Internet Data Center
• A MOSS 2007 rollout
• An internal CRM
• A new version of a flagship product
• A major services contract with a long term commitment

Get it? Any really big deal that will be around for a long time and generate a big piles of code, work, or revenue can be an Epic. Now that we can see what our Epics are, what do we do with them?

Start With a Roadmap

An Epic Roadmap is a clear, concise, and ubiquitously available document that provides a guidance for general features or accomplishments over the course of time. A good roadmap is essential to scaling Scrum, providing long to medium term direction, and communicating with stakeholders and clients.

Here is a fictitious Epic Roadmap for a year in the life of MOSS at a major organization.

2008 Q1	2008 Q2	2008 Q4	2008 Q4
Release initial team sites	Institute corporate blogging	Automate HR resume tracking with workflow	Enterprise Scrum backlog site
Release initial My Sites	Simple defect management site	Automated expense reports with InfoPath forms	Implement time tracking for professional services engagements
	Implement  enterprise search with the BDC

And Then Create a Backlog that Supports the Roadmap

The collection of Epic Backlog Items can be written in sets, each set directly supporting one of the significant areas of work in the roadmap. For example, if we look at just 2008 Q1 of the above roadmap, there will be some work around introducing the My Sites feature of MOSS to the company. A backlog of work for this feature rollout may look similar to this:

• Configure sustainable authentication and roles based security model for My Sites features.
• Train the company on the My Sites feature.
• Disable personal blog sites capability in Share Point.

Obviously, some of these backlog items are fine grained and some will need to be further decomposed into smaller items later. For example, in a larger organizations, there may be many training sessions for many different teams.

Summary

Although Epics are needed to manage large systems or initiatives, they are really just a large scale backlog item. Epics still foster a very one dimensional, albeit hierarchical, representation of our backlog. This role that Epics play is important because without it, there would be not good way to talk about big systems, or to fund big initiatives.

Slicing through Epics with Themes is a subject we will explore in a later article.