Use Cases in an Agile Backlog

by Matt Terski   from   http://blog.casecomplete.com/post/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

For 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.