Back to top

Use Cases and Scrum

Author(s) 

Making the most of both

This is the second in a series of blogs about “use cases in practice” aimed at development teams and coaches interested in finding the right practices to use for the development challenges that they face. You can read the first article here.

Natural partners for delivering value early and often

In the previous blog in this “Use Cases in Practice” series, we looked at how use cases help the team to focus on delivering value, and how use-case slices enable us to find thin slices of real user value that are small enough to enable us to deliver new increments of solution value early and often1.

A key goal of Scrum2 is to provide a management framework to help cross-functional teams to collaborate to develop new releasable increments of value on a frequent and regular basis3.

So, it seems natural and obvious that, in theory at least, use cases and Scrum should be ideal partner practices that together enable teams to:

  • Identify and prioritize thin slices of value that can be independently developed and tested
  • Collaborate to develop releasable product increments to progressively realize this value.

And in practice it is indeed the case that these two practices are extremely powerful and effective when used together.

Avoiding Anti-Patterns

In particular, using use cases with Scrum can help team to avoid some common Scrum anti-patterns, including:

  • There is no clear and objective basis for prioritizing product backlog items
  • Too much effort is put into solution aspects that deliver low or no independent value
  • Critical requirements are missed, or discovered late
  • Working software might be created and demonstrated each and every Scrum sprint, but nothing results that can actually be released, because it does not support any cohesive “end-to-end” usage to realize end-user goals and value.

How to start identifying good candidate product backlog items

In the last blog we used the example of an endeavor to develop a new digital service to enable students to apply for student loans.

We showed how, to identify small increments of value, we need to “slice” the use case or use cases “horizontally” (as illustrated below). Each such “use-case slice” represents an “end-to-end” interaction with the service that delivers true end-user value, because it enables a known subset of the user population to achieve their goal of applying for a loan.


Figure 1: Use-case slices enable a subset of users to get real value by achieving their goal.


When used with Scrum, each of these use-case slices can be placed in a product backlog4 as a candidate product backlog item5.

How to avoid bad product backlog items (no releasable value)

When an agile team does not use a “use-case slice” strategy to support an agile delivery approach, the anti-pattern that often results is that product backlog items are created by “dicing” the application “vertically” into a set of “baby steps towards value”, e.g. as illustrated below:


Figure 2: Anti-pattern of backlog items that are steps towards value, but of no independent value.


This feels easy and natural for everyone because:

  • Product owners can easily write small user stories for these baby-steps towards value
  • User-interface designers know how to design screen maps for each step to be taken
  • Developers and testers can independently develop and test these small use-case steps.

Everyone is happy. Except that there are two types of people that, if they but knew it, would be very unhappy indeed:

  • The users – who get nothing of value that they can actually use until right at the end of the endeavor, when all steps for the whole use case have been developed and tested
  • The funders – who are getting the worst possible return-on-investment deal – big up-front investment and risk, with no return whatsoever until towards the end of the project.

As we have seen, “dicing” the use case in this way is breaking the golden rule “at the heart of Scrum” that each Sprint produces something that we could release. This matters because we lose the key bottom-line benefit of an agile delivery approach, which is the economic game-changer of accruing value back into the organization incrementally, thus increasing profitability and decreasing exposure and risk.

It is no surprise that this happens so often in practice. Without the right techniques to help us it is actually very hard to identify genuine independent value that is small *enough to build, *test and release each and every sprint6.

What Use Cases add to the mix

As well as the core benefit of enabling thin slices of genuine value to be identified and progressively delivered, use cases additionally enable us to:

  • Objectively prioritize each value slice to maximize overall value return
  • Ensure it is clear how each value slice can be independently developed and tested
  • Adopt an acceptance-test-driven development approach that focuses us on doing exactly what is needed to complete a new valuable, acceptable and releasable increment
  • Split product backlog items as-and-when-needed into thinner and thinner slices, each of which still delivers new end-user value
  • Regularly inspect and adapt the work priorities to ensure key aspects of value are not missed.

How it works in practice

To show how this works in practice, I will follow a roughly sequential sweep through the key ways in which use cases and Scrum can be used together to enable us to “make the most of both”.

Clear and Visible Value and Context

A use-case model diagram provides a simple, big, visible indicator showing who the users are and what goals they need to achieve to get value from the solution.


Figure 3: A use-case model diagram is a big picture of the scope and purpose of the solution


Drawing this picture is an ideal first step to building a product backlog (or to help with refining an existing backlog). And making it visible to the team and the stakeholders provides a clear and constant reminder of the purpose of the solution and value context of the product backlog items.

Focusing first on the most important use cases enables the “top of the backlog” to be refined ready to progress first. In the example above, this is clearly the primary Apply for Student Loan use case. The other use cases support various unusual or exceptional cases and will not be needed until later, or may be supportable “manually” in early releases.

The use-case model subsequently provides the value context for all key prioritization and related decisions, for example by asking the following questions for any proposed enhancement or change:

  • Does it relate directly to a use case – if not, why are we doing it?
  • Which use case does it impact and how valuable/urgent is this use case?
  • Is it critical to achieving the goal of the use case (or just very useful, or even of only marginal value)?
  • Does it impact all use-case slices, or just some?

Independently Valuable Backlog Items

Critical to Scrum is that each and every sprint we prepare a new releasable increment of the product. To be releasable the product must enable at least one user to achieve at least one goal at least slightly better (faster, cheaper, happier).

The Use-Case 2.0 practice provides guidance and techniques for slicing use cases into thinner and thinner slices on an as-needs, just-enough, just-in-time basis, such that each one still delivers end-user value.

Use-Case Test-Driven Development

To achieve new value each and every Sprint we need to stay focused on building exactly what is needed to add new value to the product – no more, and no less. An important technique for achieving this focus is sometimes known as Acceptance Test-Driven Development (ATDD)7.

The Use Case 2.0 naturally supports ATDD, through the identification of use-case test cases that help define, drive and test the correct end-to-end execution of a use case slice. For example, one test case might be:

A national resident degree student with no previous loans should have a loan application of anything up to £10 000 approved in principle automatically.

Each use-case test case is something we can:

  • Agree with the product owner
  • Script and automate
  • Code until the test is passing.

In other words, test cases can help us identify even thinner use-case slices – each individual test case potentially being a use-case slice in its own right that we could independently code, test, prepare for release and even potentially actually release.

Collaborative Design and Planning

Great agile teams construct a sprint plan by sketching out the solution design in the sprint planning meeting, including the component collaborations required to realize each backlog item8.

The resulting design sketch is known as “use-case realization”.

Each identified new component responsibility represents something that the team needs to build and test that can be estimated and planned for the sprint, i.e. it becomes a development task on the sprint backlog. (Note these are “tasks” not new product backlog items because they are only valuable as part of the end-to-end interaction needed to implement a use-case slice).

Inspect and Adapt the Increment

We have already seen that the use-case model provides a simple, big, visible picture that provides critical value context. This represents a powerful tool that can be used as part of Scrum sprint reviews to ensure that the team and the stakeholders reflect meaningfully on what has been achieved in the context of the overall solution goals and value, and adjust future work objectives, priorities and plans accordingly.


  1. Throughout this series of blogs the Use Case practice that we refer to and use is IJI’s Use Case 2.0 practice https://practicelibrary.ivarjacobson.com/content/use-case-20-essentials-publication↩︎

  2. As described by The Scrum GuideTM and the Scrum Essentials cards↩︎

  3. “The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.” https://scrumguides.org/scrum-guide.html#events-sprint↩︎

  4. See https://scrumguides.org/scrum-guide.html#artifacts-productbacklog ↩︎

  5. Although in this initial form they may well be flagged as “epics” (see for example https://www.agilealliance.org/glossary/epic) – i.e. things we know in their current form are too big to fit into a Sprint, and that will need to be split down smaller as part of product backlog refinement before we can actually plan them into a Sprint (see later for how to do this). ↩︎

  6. I deliberately use and emphasize key elements of Bill Wake’s most excellent INVEST mnemonic https://en.wikipedia.org/wiki/INVEST_(mnemonic)↩︎

  7. See for example https://www.agilealliance.org/glossary/atdd↩︎

  8. I know this because I have witnessed it many times, including for highly complex and sensitive system developments, and an impressive and beautiful sight it is to behold. Unfortunately I have also experienced less great teams declare that such a thing would be quite impossible! ↩︎

Subject