Cockburn Affirms: Use Cases Rule for Agile!

chocolate chip cookie

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.

requirements structure

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


Use Cases Rule! [“If it’s our blog, then it’s our pizza.” – Mr. Hand from Fast Times at Ridgemont High]

7 thoughts on “Cockburn Affirms: Use Cases Rule for Agile!

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

  2. Hi Scott,

    I am conducting a training course about Lean Functional Spec. I found the first diagram in this article quite useful (1. Gaining Context With Use Cases.

    I wanted to ask for your permission to use this diagram in one of my slides.

    Please contact me on “” and let me know whether you would like to grant the permission or not.

    I obviously appreciate if you allow me to use this slide or otherwise I won’t be using it.

    I appreciate if your prompt respond.


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



Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.