Learn about Use-Case 2.0

Everything from User Stories but more!
Use cases is a well-proven technique for doing requirements and it has been part of the inspiration for more recent techniques such as user stories. Now the inspiration has flown in the other direction. Use-Case 2.0 is the new generation of use-case driven development – light, agile and lean – inspired by user stories, Scrum and Kanban. Use-Case 2.0 has all the popular values from the past, not just supporting requirements but also architecture, design, test, operations, user experience, and also instrumental in business modeling and software reuse. In fact, the use case idea has become so widespread that the term ‘use case’ has become a normal English word used to understand the usages of virtually anything. Principles of Use-Case 2.0


Use-Case 2.0 ebook

Learn the Agile Way to Do Use Cases

Use-Case 2.0 re-focuses on the essentials and offers a slimmed down, leaner way of working, for software teams seeking the benefits of iterative, incremental development at an enterprise level.


Use-Case 2.0 is ideal to work with Agile frameworks like Scrum at Scale, Disciplined Agile and SAFe. You see the big picture and help your teams understand how a system will be used, and the value it will provide to its users and other stakeholders.


Use-Case slices reinforces agility incrementally – stop throwing away everything when you go from release to release – grow it and add more with use case slices.


  • Never lose sight of the big picture when working with Use Cases. Zoom in to the precise level of detail needed. Unlike User stories which can create a wad of documents that a) don't support your way of working and b) are lost and irrelevant once the system is live .
  • Use-Case slices reinforces agility incrementally – stop throwing away everything when you go from release to release – grow it and add more with use case slices.
  • With Use-Case 2.0 you have an auditable requirements spec at the end, rather than just a huge pile of story post-it’s in the garbage bin.
  • See the big picture and help your teams understand how a system will be used, and the value it will provide to its users and other stakeholders.
  • Use cases help you bind together the whole life cycle – from design to testing – See the whole picture but don't lose the details so you can set priorities * Use Cases allows for better documentation and communication between all groups.
  • Well-written Use Cases provide insightful guidelines for the design of test cases and user manuals of the system or product.

Use-Case 2.0: The Hub of Software Development

Use Cases are the Hub of the Software Development Lifecycle

Use cases have been around for almost 30 years as a requirements approach and have been part of the inspiration for more recent techniques such as user stories. Now the inspiration has flown in the other direction. Use-Case 2.0 is the new generation of use-case driven development – light, agile and lean – inspired by user stories, Scrum and Kanban.

Use-Case 2.0 has all the popular values from the past, not just supporting requirements but also architecture, design, test, user experience, and also instrumental in business modeling and software reuse. Use-Case 2.0 has been inspired by user stories to assist with backlogs à la Scrum and one piece flow with Kanban, with the introduction of an important new concept, the Use-Case Slice.

We will make the argument that use cases essentially include the techniques that are provided by user stories but offer significantly more for larger systems, larger teams, and more complex and demanding developments. They are as lightweight as user stories, but can also scale in a smooth and structured way to incorporate as much detail as needed. Most importantly we will show that they drive and connect many other aspects of software development.


Features or Use Cases – Which is Right for You?

How to be value-driven and deliver value early-and-often

Editors Note: This is the first in a series of blogs aimed at development teams and coaches interested in finding the right practices to use for the development challenges that they face.

Every development endeavor is different

Some are more different than others. Let’s take a couple of extreme examples.

If what you are building is a smartphone app, then it’s often all about shiny, attractive features1, right?

So, a good place to start might be to brainstorm lots of possible “killer features”. Then agree which you want to build into a first Minimum Viable Product (MVP)2. Then chop these up into smaller “Product Backlog Items” or “User Stories”, so that you can build, test and demonstrate many of these each development heartbeat or Sprint (if you are using Kanban or similar lean “continuous flow” approach).

But what if you are automating a complex business process, or building a new digital service, such as (to take a few examples from the author’s development project experiences):

  • Online loan applications – from initial application to loan offer
  • Trade Processing – from initial trade to account postings completed
  • Organ transplant – from donor-recipient matching to organ transplant procedure
  • National statistics calculation – such as headline inflation or unemployment figures.

Here “shiny features” are not of primary importance. Sure, if you ask users to brainstorm what features they want, they will tell you. But if you start to build the solution one such feature at a time, the chances are you won’t have a system that is usable in a live environment for a very long time. Which, as an approach to maximizing value/return-on-investment, basically stinks.

With these kinds of systems we need to take a different approach to being value-driven and to delivering new value early-and-often.

Focusing on Value

A useful guiding mantra with these kinds of systems is “if some users can achieve an end-goal, then we have built something of at least some value that we could potentially release”.

So, with this kind of system in particular, a great first question to ask is not “what features could we build”, but rather “what kind of people will use this” and “what will they use it for”.

Answers to the second question are known as “use cases” and answers to the first question are known as “actors”. Both answers can be neatly captured in a "big visible information radiator" as a use-case diagram, for example as shown to the right:

Figure 1: A Use Case enables a user type (Actor) to achieve a goal (and therefore get value)

Even for large systems, there are often relatively few of these use cases – maybe up to a dozen or so. Of these, sometimes there are as few as one or two use cases that we will want to focus on initially for a first product release, such as the “Apply for Student Loan” use case shown above.

This is both the good news (relatively few use cases) and the bad news (a single use case can represent a significant percentage of the total system build time/cost).

So, in order to be able to deliver value early-and-often, the next step is to start cutting these big use cases into smaller parts.

Use-Case Steps

There are two different directions in which we can start to “cut” – horizontal or vertical3.

An obvious way to cut such a use case is vertically into “steps”, for example as shown below4:

Figure 2: Identifying smaller “steps to value” within a Use Case

These steps are useful things to recognize for the development team. For example, we can design screens for each step, prototype them, and even test these screen prototypes with end-users.

But if we were to incrementally build and test the system one of these steps at a time, the BIG problem is we won’t have anything that enables any users to achieve their goal until we have built all the steps, which is often pretty much the whole system. Which, as we have already said, is the worst possible way to maximize value/return-on-investment.

Finding Slices of Releasable Value

The key to finding releasable subsets of the whole system is to split the use case in the opposite direction – by identifying “end-to-end”, “horizontal” use-case “slices”, each of which achieves at least some end-users’ end-goals, and therefore realizes at least some genuine end-user value.

Often with complicated business processes there are a huge number of possible paths through the system. An easy way to define releasable increments is to constrain the set of paths that each release will support. For example, a first release of a Process Trade use case might be designed and built to support only the cases where Trade Instrument = Shares; Trade Location = UK; Account Location = UK; Exchange = UK Stock Exchange; Trade Currency = UK Sterling5.

And to figure out the best order to “build and release” our slices, we can use a simple, standard economic model, informally known as “bang-for-buck” (and more formally known as “Weighted Shortest Job First” or “Cost-of-Delay-divided-by-duration”)6. For example, if the above trade processing “slice” is roughly 80% of our business by value, and only roughly 20% of the complexity of the whole system, then this might be a good thing to build and release first.

If we return to the student loan example, the result of slicing the use-case in this way might look as shown below7:

Figure 3: Use Case Slices are end-to-end paths through a Use Case taken by a subset of cases

The IJI Use Case 2.0 Practice includes guidance and techniques for progressively splitting thinner and thinner slices as required to support a value-driven, lean/agile delivery approach at every level, for example:

  • To initially identify top-level slices that represent candidate releases
  • To slice thinner as needed to find candidate Product Backlog Items
  • If a candidate Product Backlog Item is too big (e.g. to fit into a Sprint), to slice even thinner as and when needed – potentially as thin as a single end-to-end test case if needed.

Using Use Cases in Combination with other Practices

As we will see in later blogs, this approach to slicing thinner and thinner slices of end-user value is a powerful practice that can be used in combination with any number of agile management practices and frameworks, including Scrum, Kanban and SAFe®.

The only challenge is that these different management practices use different names for “small things that we progressively build into the product to increase its value”, for example:

  • In Scrum, these are called “Product Backlog Items”
  • In Kanban they are called “Work Items”
  • In SAFe they are called different things at different levels - Stories, Features, Capabilities etc.

The bottom line is that Use-Case Slices make great Product Backlog Items / Work Items / Features / Stories etc. because:

  • They are by definition ndependently valuable8.
  • They can be sliced and sliced again on an as-needs, just-enough, just-in-time basis to make them small enough to be flowed efficiently through a development process (including down through different levels of backlog in a multi-level scaled agile model).

Use Cases or Features?

Returning to our original question, we can now see clearly that it is the wrong question to ask!

We should not be thinking “features or use cases”, but rather about what is the best way to:

  • Identify and prioritize small increments of releasable value (candidate releases)
  • Split these (if and when needed) into smaller items that we can independently prioritize, schedule, build, test and demonstrate (product backlog items).

Use-case slices are a simple but powerful technique for doing exactly this.

They are especially invaluable when the solution we are building is the automation of a business process, such as an e-commerce, digital service, or “straight-through processing” system. But even here we might use a combination of use cases with other approaches to identify the different kinds of value we could build into the product, e.g. “features” that add extra value to many use-case slices, such as a “Loan status text alerts” feature for example.

And it matters not at all what we choose to call the results of the use-case slicing process – they might become candidate MVPs, MMPs, Features, Product Backlog Items, User Stories, Work Items or whatever our chosen work management practices choose to call these value increments and items.

  1. “Feature” is a popular concept with a long and varied history (including as part of the Rational Unified Process (RUP) , Feature-Driven Development (FDD), Scaled Agile Framework (SAFe) etc.) and, unfortunately, is defined and applied differently each time (http://www.jot.fm/issues/issue_2009_07/column5/ for example lists 10 different definitions). In general, and loosely speaking, a feature tends to be anything of significant, independent value – the kind of thing that might be listed “on the back of the box” (or in the brief description of an app in an app store), and this is the general sense in which I use it here. Note that SAFe Features have a very specific meaning and play a very specific role in that framework (see https://www.scaledagileframework.com/features-and-capabilities). I intend to look specifically at SAFe Features in a separate blog on using use cases with SAFe.↩︎
  2. I use this term in its “original” meaning, as introduced by Eric Ries in “The Lean Startup”, and further elaborated by him in “the Startup Way” – i.e. as a “limited liability experiment” to learn by testing a hypothesis, NOT a fully engineered, generally releasable product. The latter I shall refer to as a Minimum Marketable Product (MMP)↩︎
  3. While the “horizontal” versus “vertical” distinction is common in software development, unfortunately it varies as to which means what, depending on which way around you happen to draw your diagrams! I stick throughout to the most natural orientation when using Use Cases, which is that “horizontal” is an “end-to-end” interaction that culminates in the achieving of the end-goal of the use case, whereas “vertical” is a non-releasable chunk of software, either comprising a solution implementation layer (e.g. “just the user interface”) or just one step towards value (e.g. “just the initial user registration step”).↩︎
  4. Here we are showing the “normal flow” case (sometimes called the “basic flow”) – the typical way the loan process flows “end-to-end” – there are clearly many possible “alternative” or “exception” paths, but for the sake of brevity we will not consider these here.↩︎
  5. Which was roughly what happened with the new trade-processing system that this example is loosely based on. In the first release of the new system all other trade types were simply intercepted “at the front gate” and channelled through the existing system.↩︎
  6. See for example Donald Reinertsen’s “The Principles of Product Development Flow”.↩︎
  7. Also loosely based on a real example.↩︎
  8. I deliberately use and emphasize key elements of Bill Wake’s most excellent INVEST mnemonic https://en.wikipedia.org/wiki/INVEST_(mnemonic).↩︎

Use Cases and Scrum

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 Guide 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! ↩︎

Aspect Oriented Software Development with Use Cases - (2005)

Authors: Dr. Ivar Jacobson, Pan-Wei Ng

Aspect orientation promises to be the next big wave in software engineering, following on the heels of the object-oriented paradigm. Proponents tout the value of aspect orientation in providing the ability to add extremely useful mechanisms such as security, logging, persistence, debugging, tracing, distribution, performance monitoring, and exception handling.

To state it simply, it makes programming and programs more efficient. This highly-anticipated new book demonstrates how to apply use cases and aspect orientation in building robust and extensible systems.

The authors show you how to identify, design, implement, test, and refactor use case modules and how to extend them. The book also demonstrates how to design use case modules with UML including some enhancements made in UML 2.0 to better support the modeling of use case modules.

Read more on Amazon.

Use Case Modeling - (2002)

Authors: Kurt Bittner, Ian Spence

Developers who effectively employ use cases deliver better applications-on time and under budget. The concept behind use cases is perhaps as old as software itself; they express the behavior of systems in terms of how users will ultimately interact with them. Despite this inherent simplicity, the use case approach is frequently misapplied, resulting in functional requirements that are confusing, cumbersome, or redundant.

In "Use Case Modeling", experienced use case practitioners Kurt Bittner and Ian Spence share their tips and tricks for applying use cases in various environments. They delve into all aspects of use case modeling and management, demonstrating how development teams can capitalize on the approach's simplicity when modeling complex systems. In this ready reference, readers will discover how to:

  • introduce a development team to use cases and implement a use case approach;
  • identify the key elements of a use case model, including actors; and the components of a use case, including basic flow, preconditions, post-conditions, sub-flows, and alternate flows;
  • master the objectives and challenges of creating detailed descriptions of use cases;
  • improve their descriptions' readability and consistency;
  • prevent and remedy common problems arising from the misuse of include, extend, and generalization use case relationships;
  • organize and conduct a review of a use case model to realize the best possible approach.

The book draws extensively on best practices developed at Rational Software Corporation, and presents real-life examples to illustrate the considerable power of use case modeling. As such, Use Case Modeling is sure to give development teams the tools they need to translate vision and creativity into systems that satisfy the most rigorous user demands.

Read more on Amazon.

A world-leader in large-scale modern software engineering

Our world-class experts and unique pioneering practices and tools provide the catalyst for change, guiding your teams at all scales to realise their full agile potential in the shortest possible time. We leave behind a long-lasting step change in capability – accelerated smart teams and an ever improving organisation.

Creating winning teams.

Connect with us: