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!

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!”

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, …”):

Designers lack the context of the goal that the user is trying to achieve.

The team does not get a early indication of the scope of the project.

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.

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.

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.

Thanks David, and welcome to Tyner Blain! Yes, this article slipped through with at least a dozen errors. My apologies to you and everyone else here. I’ve done a quick copy-edit, and hopefully it reads better now.

Please take a look at Foundation Series: Structured Requirements , which is where I reference Karl Weigers’ original diagram – from which that diagram evolved – and consider giving Karl credit for his original work, as I did. We wouldn’t be where we are today without his great work.

Hi Scott, great article and enjoyed it thoroughly. Here are some thoughts, especially when you are using a robust repository based modeling tool i.e. ARIS and marrying software development with enterprise architecture principles – both in a model driven environment. Here are some steps that can be followed when executing a business project spanning multiple business domains and applications:
1. Define the scope and context of the project and identify the key business capabilities / processes impacted. Treat the capabilities / processes as architecture building blocks (ABB’s in TOGAF) and reuse form the business architecture domain on the project context diagram.
2. For each identified capability / process, define the 1st level end to end process definition using BPMN and identify key requirements by associating user stories to relevant activities i.e. user tasks, service tasks, transactions, sub – processes etc.
3. Consolidate the above in one use case model and harvest (copy) the relevant activities with associated user stories (requirements) to the use case model. Add human and technical actors. From here one can then estimate the effort using use case point calculations as explained in one of your articles.
4. Use cases are then expanded by completing the use case narratives and use the user stories to formulate the normal flow, alternative flow detail etc. User stories are therefore used to complete the detail use case narratives.
5. Additional modeling tasks can then be associated to use cases as required i.e. screen navigation for consumer use cases & associated screen designs etc.

@sehlhorst on Twitter

Who Should Read Tyner Blain?

These articles are written primarily for product managers. Everyone trying to create great products can find something of use to them here. Hopefully they are helping you with thinking, doing, and learning. Welcome aboard!