Cockburn Affirms: Use Cases Rule for Agile!

We’ve been promoting use cases as the right way to approach agile requirements, and in a recent article, Alistair Cockburn stresses the importance of use cases. Over the last three years, he has found that teams that avoid use cases consistently run into the same three problems. We defer, of course, to Alistair as the expert. But we’ve been independently promoting this practice too. So today, we get a cookie!

Alistair Promotes Use Cases for Agile Development

First, a hat tip to Rajeev Singh for pointing us to Alistair’s defense of use cases in agile projects. In discussing his findings from the last three years of talking to agile project teams, Alistair writes:

I keep running across organizations suffering from three particular, real, painful, and expensive problems.

[...]

In particular, use cases fix those three problems.

I’ve been testing this out for the last 3 years – I walk in and ask, “On your agile project(s), do you by any chance suffer from any of these three things?” … and then list the three … Much stronger than even I expect, there hasn’t been a single organization I asked these of that hasn’t said, “Oh, Yes, and How!”

Why I still use use cases, Alistair Cockburn

Alistair finds these problems both when teams replace use cases with user stories (or use scenarios) and when they eliminate either approach and move to a feature-driven product backlog.*[See "Scrum" Section at the end of the article.]

Paraphrasing the three problems (”Without use cases, …”):

1. Designers lack the context of the goal that the user is trying to achieve.
2. The team does not get a early indication of the scope of the project.
3. Alternate user-behaviors are not identified in advance of the commitment to deliver.

How do use cases address these problems?

1. Gaining Context With Use Cases

Even in agile projects, use cases are an enabling mechanism for companies to achieve goals. An approach that uses structured requirements provides that context.

Each use case exists in the context of the goal. A couple years ago we wrote about the reasons for writing use cases. Those goals could easily be addressed with use scenarios and user stories. The problems that Alistair articulates arise from choosing something other than use cases to meet those goals.

2. Getting An Early Indication of Scope

Politically, the largest problems in getting an agile project launched in a waterfall organization comes from mis-set expectations. Setting expectations and thereby securing both funding and support for a project can be more important than execution.

If you don’t have the support of a sponsor, your project will fail. If you have sponsorship and funding, your product could still fail. Both are necessary, neither is sufficient.

To set expectations, you have to identify the scope of your project immediately. Here’s an example of the scope definition for our nexus project from last year. Setting scope is as much about managing stakeholders and prioritizing stakeholder objectives as it is about controlling delivery time frames and schedules. [Tangent Warning: even if it means delivering incomplete requirements.]

The key is to get a breadth-first overview of the scope, and then a deep understanding as you iterate.

3. Avoid Scope Creep With the Rigor of Use Cases

As Alistair points out, this is hard to differentiate from “managing scope.” The distinction is that the scope-definition issue is one of discovering functionality broadly, where this scope creep issue is one of understanding complexity sufficiently.

The right approach to defining use cases for agile development starts with a definition of scope. Once you’ve defined the scope, you define the use case names, then progressively prioritize and define the use cases in more detail, in priority order, as you incorporate them into your time-boxed project schedule. You also refactor your use cases, consolidating and defining subordinate use cases where appropriate, and defining extension use cases as needed.

Scrum

Scrum, as an organizational approach to agile does not preclude the use of use cases. Scrum projects commonly choose to use a feature-driven backlog. We actually really like scrum as a mechanism for managing delivery. But we feel that it works most effectively when time boxing each iteration specifically in terms of use cases. When using use cases as the quanta of your iteration backlog, you get all the benefits defined above, plus the benefits of Scrum as a delivery vehicle.

Conclusion

Use Cases Rule! ["If it's our blog, then it's our pizza." - Mr. Hand from Fast Times at Ridgemont High]

This article was published on Monday, February 18th, 2008 at 10:41 pm and is filed under Agile, Business Analysis, Product Management, Requirements, Requirements Models, Software development, Use Cases.
You can leave a comment on this post.
Trackback URL