You probably read the title and said to yourself: “Epic: you keep using that word, but I don’t think it means what you thinks it means”.

It is true. The fixed-price agile backlog exists.

Now, if you are lucky enough to have never faced such a beast, then I bow to you and wish upon you continued good fortune. However, many of us have lived Agile in the Iron Triangle. Many of us have walked away as shattered and broken shadows of our former selves. We have lived, lost, learned, and ranted to whomever would listen.

This post is brought to you by an experiment in requirements cross-checking.

Too much agile?

One of the greatest things about the agile movement is that most of the teams I now work with don’t even remember the old waterfall ways anymore. Writing user stories and prioritizing and estimating with relative points is so ingrained that nobody even thinks about it.

Did something new come up during a demo? Sure, queue it for the next sprint.

Did a business requirement change? No worries, a new story is on its way.

Did we not over-analyze all the user flows up front? Not a problem, we’ll clarify requirements as we go.

What do you mean we can’t have more budget for the 50% extra development now required?

Identifying fixed scope

Sometimes you get faced with what is so obviously a waterfall project that an agile team struggles to adapt. Lots of up-front planning, fixed scope with fixed price and timelines, assumptions and caveats all over the place… a recipe for agile disaster.

One of the struggles is to identify what requirements can actually be accomplished within a given budget. Even if your team constructs a thousand user story definitions you can’t be sure you have things covered. Your wireframes have gone through umpteem revisions and discussions with the stakeholders, but is everything there? How do you know if you missed something?

The Epics cross-check

In these scenarios I recommend a two-pronged cross-check:

1. Wireframes vs. Backlog
2. Epics vs. Backlog

The wireframes cross-check is fairly straightforward.  If there is something in the wireframes, is there something in the backlog that describes it?

The epics cross-check is somewhat different. Some teams are pretty strict about having all their user stories match up to an epic story, while others might jump straight to their story backlog and skip the epic definitions altogether. When dealing with a fixed scope backlog definition, I recommend getting those epics together!

An epic can be used to validate that you have stories that cover all elements of the interaction; from beginning of the user’s task to the end when they accomplish their goal. By using a flow definition, we can validate that our backlog is accomplishing our user’s key tasks.

What does this epic look like?

Epics generally take the same form as a typical user story:

As a goalie, I want to buy some low-cost 36″ used leg pads because I am tall, pretty terrible, and wish to avoid spending too much cash on my hobby.

The above is a very simple epic story description of a TOTALLY FICTIONAL person who needs to replace their goalie pads and is visiting a store website to look for the desired product.

From a backlog perspective, there are several things that go into supporting this single flow. There is an implication of a product catalog with filters and pricing, and some sort of e-commerce flow to purchase the product. As time goes by on an agile project, this would be refined to small incremental implementation stories.

Not so in the fixed backlog.

We need to know that we didn’t miss something now, so the low-cost approach to that is to cross-check the backlog, but we need more information then the simple description.

Acceptance Criteria might be the obvious next step, but this can be very costly to define all business requirements for the entire flow when we may have already done that in the user story backlog.

The middle-ground is defining a user flow:

• User visits the main page of the store website.
• User clicks in the navigation to access the product catalog.
• User selects a filter to show only goalie pads.
• User selects a sizing facet to restrict to 36″ pads.
• User sorts the results by price.
• User selects a result to view the details.
• User adds the result to a shopping cart.
• User reviews their cart and proceeds to checkout.
• User provides their billing information and proceeds to confirmation.
• Credit card information is validated and confirmation displayed.
• User reviews the details and submits the order.
• The order is created in the order tracking system.
• The user is notified of their order number and tracking information.
• The user is emailed a copy of their receipt.
• The account manager receives a notification of the submitted order.
• The account manager reviews the order and submits necessary information for the store to ship the order.
• The store receives the order information, packages the product, and ships it to the consumer.
• The user receives their package.

The example above is very detailed, but doesn’t take long to write. We don’t need to worry about alternate “what-ifs” and such, just enough to get an idea of the common flow.

What do we do with this epic?

The first goal of writing the user flow for the epic is to get the product owner to think about the user experience of the user going from start to finish of a task. It exposes:

• Potentially missing User Experience flows in the wireframes
• Possible system integrations
• Stakeholders that may not have been engaged

The second goal of writing the user flow is to start checking if we have stories in our backlog that support each step of the flow. Did we remember to cover credit card validation for the example above? Maybe we forgot that the item actually needed to be shipped and now we realize we need a story for the user to provide shipping information? In any case, we can use this to validate that there are not missing stories in our backlog.

How do we know if we got them all?

I suggest tagging your stories with the associated epic as you check each epic. Create any missing stories as you go along and tag them similarly. When you are done, you should have a backlog full of stories tagged with epics.

For any story in your backlog that wasn’t tagged with an epic, you need to ask yourself:

1. Did I forget a user flow or step in a user flow?
2. If not, why do I have this requirement?
3. If it’s a valid requirement and there are no missing flows, how does the user trigger this? (HINT: You probably are missing a flow and were wrong about #1.)

Caveat: If you missed the story, missed it in the wireframes, and missed the user flow, this cross-check won’t find a problem. It probably also means that nobody cares about that feature. 🙂

Hopefully this helps you the next time you are asked to put together a backlog with every single story in it. I also sort of hope you never need any of this!