Use Cases in an Agile Backlog

A question I’ve been asked a lot lately is, “How do I make use cases work in an agile setting?” I found myself struggling for an answer because a) agile is a mindset not a methodology and b) I didn’t think there was anything about use cases that prevented them from being used in an agile setting. So just do it. But I think the questioners were looking for something more prescriptive. So let’s break it down.

The Backlog

BacklogFor starters, use cases are a form of requirements, and when we’re being agile, requirements go in the backlog. Often, those requirements take the form of user stories, but they could also be use cases. If they were, how might this work? Consider the composition of the backlog. The items down at the bottom, furthest away from being implemented, are described in a coarse manner. Probably just a name and maybe a description. This feels right since you don’t want to invest much time or energy in requirements long before they will be designed or implemented. That would be the opposite of agile.

So use cases would enter the backlog as a simple name and description. Almost like a placeholder – or an agreement to have a conversation later. This reminds me of the definition of a user story actually. One difference would be, we’d eventually write down parts of that conversation in the form of a use case.

As use cases percolate higher up in the backlog, we’d add more detail to them: a success scenario, some alternate scenarios, maybe related requirements or a wireframe. The risk to avoid here is investing too much effort in detailing use cases that are further down in the backlog. Don’t write documentation you don’t need. The line you want to to be weary of crossing is writing more detail than what is needed to deliver your next iteration.

A Use Case: Too Big for a Sprint?

I think of use cases as one way to group a set of requirements: a user goal, scenarios, constraints, business rules, wireframes, diagrams, etc. As much as I like use cases, one challenge with agile will be, they are too large to be considered an atomic unit of work. By themselves, they don’t make for a useful burn down chart. In fact, you might not fit a complete use case into a single sprint. So the use case – this grouping of requirements – needs to be broken down into some other logical chunks of work.

I’ll cover what those chunks are in my next post.

What do you think? Are use cases and an agile backlog a complete mismatch? Let me know in the comments.

Comments (4)

12/19/2011 6:20:40 AM #


In an Agile environment I have created a feature backlog item with the Use Case name. When it is time to flush out the details of the feature, I describe the use cases main flow, alternative flows, exception handling, etc. in seperate backlog items and link these items to the use case feature backlog item. The fluffy use case details are maintained in the Featured Use Case, such as the actors, goals, use case description, preconditions, post-conditions, Triggered Events and supplementary documents.  If using Case Complete with MS Team Foundation this works very well in organizing the requirements. You will be able to create queries to see the hierchy of the requirements.

Melissa United States

12/22/2011 9:58:26 AM #

Jake Calabrese

I certainly believe that use cases can be included in a backlog.  Like Melissa says, entering them really as actor goals (use case name) is really the start.  

How you decompose them is the key. People will run into problems if they are stuck in the mindset where they believe that a use case must be detailed out in long form with every conceivable extension before beginning work on it.  You need to start small and develop just enough detail of the use case based on what parts of the use case move to the top of the backlog. This is important to note - since the main scenario may be at the top of the backlog but some (or all) of the extensions may not be...

Jake Calabrese United States

12/27/2011 12:02:47 PM #

Jeffery Green

I agree with this approach of starting with a use case name in the backlog and decomposing the use case further as it gets closer to the top.  We are finding that once decomposed, use cases tend to get too large to fit into a sprint but if the use case is broken down into "sub-function" use cases then the sub-functions make a nice size piece of work in the backlog. The larger use case gives the context and the sub-functions detail out the chunks of work to be acomplished.  

Jeffery Green United States

1/13/2012 12:24:42 AM #

Wouter Slager

I think Use Cases should not be put on a product backlog.

first of all, I agree with you that Use Cases are a "vessel" to define scenario's and functionality and that most of the time they are to big to fit in one sprint.

But the main problem is that the whole idea of agile working is that things can change during the sprint and that the team is flexible in creating business value. Having a wel defined Use Case on the backlog means that a lot of the requirements engineering has already been done. You're actually going towards waterfall or rup, where one phase follows the next.

In my opinion an item on the product backlog should be described in such a way that it's goal is clear for the whole team. Based on this, Use Cases can be described, test cases can be defined and code can be written.

Reading your last line, i wont give away the solution with with to do this and will wait to your follow up post! I have a clue we have similar ideas Smile

Wouter Slager Netherlands

Pingbacks and trackbacks (3)

Comments are closed