Is it feasible to use User Stories and Use Cases in the same team?

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/364270

Question

I am trying to encourage working practices that are more agile. I am trying to understand the difference between a Use Case and a User Story. I have read a lot of articles and questions like What's the difference between "use case", "User Story" and "Usage Scenario"? and Is it reasonable to assume a 1:1 relationship between user stories and use cases?

The questions focus on how the approaches differ from a technical perspective. I am trying to specifically understand how to choose one over the over. One article suggests:

  1. Use User Stories to define Product Backlog items

  2. Use Use Case diagrams to define Sprint Backlog Items (the way I understand a Sprint Backlog is that it is the Product Backlog broken down into steps that should be completed over the Sprint).

I like the thought of this as it means Use Case techniques (like UML) can be used during the Sprint.

Is this a normal approach? If it is not then when do you use a Use Case and when do you use a User Story?

Was it helpful?

Solution

Personally I would only use one or the other, not both.

To my mind the User Story is a way of writing a spec which says, "I don't care how this is done as long as I can do it"

"As a Taxi Rider, I can see the price before I accept so that I can choose not to purchase"

Where as a Use Case defines exactly what the app should do and show.

open app->enter destination->see price->accept or reject

The User Story is attempting to push the design tasks to the developers, while the Use Case is saying, the design has been done, now implement it.

OTHER TIPS

What's a use case ?

Let's look at the definition of Ivar Jacobson, the guy who invented the concept before UML even existed:

A use case is all the ways of using a system to achieve a particular goal for a particular user. Taken together the set of all the use cases gives you all of the useful ways to use the system, and illustrates the value that it will provide.

The UML use case diagram that he invented is just an artefact that helps to focus on the goals that actors intend to achieve and the interactions to expect. This can facilitate interactive discussion with stakeholders or peers on the paperboard. But without any further description, these diagram have little added value.

Alistair Cockburn elaborated on the use case definition and description:

Use cases are goals (use cases and goals are used interchangeably) that are made up of scenarios. Scenarios consist of a sequence of steps to achieve the goal, each step in a scenario is a sub (or mini) goal of the use case. A collection of possible scenarios between the system under discussion and external actors, characterized by the goal the primary actor has toward the system’s declared responsibilities, showing how the primary actor’s goal might be delivered or might fail. As such each sub goal represents either another use case (subordinate use case) or an autonomous action that is at the lowest level desired by our use case decomposition.

Jacobson has recently updated his original approach to make it a more agile practice, promoting to slice the different scenarios of a use case into UC slices that can be worked out implemented iteratively. This is very well explained in his free ebook "Use Case 2.0"

What's the difference between a use case and a user story ?

Many articles explain it. Unfortunately, there are still many that either see use cases as their UML subset, or consider them as the old way of writing over-detailed specifications in a waterfall like fashion. Let's get rid of these caricatural sketches:

  • user stories give you a user oriented view with epics, decomposed into user stories, decomposed further if necessary, letting emerge the expected SW-features. Unfortunately, the flat backlog is a risk of loosing the big picture. So Jeff Patterson came with his user story mapping approach.

  • use case give you a goal oriented, system centric view, the goals are decomposed into more feasible goals, but if you decompose too much and to early, you're no longer agile. Jacobson came with his use-case slices in order to prevent this.

But in the end, is it so different ? Ok, the way you identify the requirements and chose to decompose them is different. But user stories also connect needs/features with goals (it's just that goals are not the center). On the other side, use cases are identified by discussing with users (it's just that they are not at the center of the model). And ok, you have to identify scenarios in a use case. But don't you need to have them in mind when defining the user story acceptance criteria ? So in the end you'll come to the same result, even if you may take a slightly different path, with different risks.

Can you use both of them in the same team ?

Sure, you can ! The question is for which purpose.

Taking user story for the product backlog and use case for sprint backlog seems to me a very bad idea. Because it would force you to translate for sprint planning the product back-log user stories into use cases. And as seen above, there is no one-to-one translation between both. So you'll create an unnecessary overhead !

So my advice would be to choose one and use it systematically.

The best one will really depend on the context. For example:

  • in enterprise projects, very often the starting point for an implementation is the (existing or a re-engineered business process). Every process step could then be seen as a kind of use case. Very quickly you come to a high volume of such individual steps (400 as a starting point is not unusual for an enterprise system), so nobody would think of showing them on an UML diagram. Instead you'd have a BPMN process diagram.
  • if you create a commercial off-the-shelf product from scratch, then it could be easier to deliver value based on user stories elaborated with personas in mind.

Additional reading

By googling around, you may find lots of article with a clear position on US vs UC or UC bashing. Therefore, I'd like in addition to the links in the text above, to recommend some resources which are more objective, as well as some resources that address the specific link between UC and business processes:

The one of the goals of both "agile" and "object-orientation", as well as a couple of other ideas like "ddd" (Domain-Driven Design) is for us developers to understand the business. Become domain experts, develop a common understanding, and a common language.

The point is not to use a specific tool, like User Stories or UML. It is to use whatever tool is appropriate for your team and culture. If developers agree to use UML to remember what was (or is being) discussed, then use that. Most of us are actually lazy and don't want that much formalism, that's why Stories work most of the time.

Also, experiment! Try with and without UML for a while, discuss with the team what worked best. The beauty of "agile" is, that there is a feedback mechanism, so you don't have to get everything perfectly right the first time, you can get better at doing things with time.

Summary: It is normal, if that is what your team wants to do. I would suggest you try with and without for a month each or so, then discuss which is more effective.

Use Cases

I would argue that a use case is similar in nature to an epic -- it describes a group of features that work together to describe how a user will use a system. User stories are created and owned by the Product Owner and Business Analyst, along with feedback from interaction designers, marketers, etc.

For example, a use case of google is something like this:

A user goes to the google home page, they start typing into the input box, a list of choices appear, they pick a choice, and are redirected to a result page that includes a list of search results. From that result page they can click on a result, at which point they will be redirected to the link included in the results.

Of course, real use cases are much more detailed, and often spelled out in a formal language or methodology if the system is sufficiently complex.

User Stories

A user story, on the other hand, is one small piece of a use case (or a small piece of an epic that is a small piece of a use case). They are written and managed by the Product Owner, often with input from other members of the team or department. The stories are used by the development team.

Example user stories:

As a user, I want to be able to go to the google home page and type into the input box in order to see a list of suggestions without submitting a form so that I can see a list of past or similar queries.

Another would be:

As a user, I want to be able to pick an item from a list of suggestions, and automatically be redirected to the result page for the selected item without clicking on the submit button so that I can quickly get to the results of a common or repeated query.

... and so on.

Can you use them at the same time?

To answer your question if you can use both, yes, you can use both. The product owner will work from the use cases in order to create epics and stories. The scrum team will work from the stories in their sprints, with the use cases being supporting documentation which they can use to help them develop the product.

Ran into the same issue on a project where mgt decided to "do Agile" but the new "Chief Programmer" was heavily steeped in linear, document-heavy processes that focused enormous energy on generating detailed written specs that nobody ever read or discussed. She didn't know what a Scrum Master was, but by golly, she was it! In trying to answer this question myself to bridge the ideological gap, the 2 key distinctions I discovered were:

1) USER STORIES are discussed collaboratively & captured less formally by the team during sprint planning to answer as many questions as possible up front w/o wasting too much time.

USE CASES are written down more formally, perhaps only by a developer or 2, perhaps all at once early on instead of per iteration, and they result in deliverables nobody ever reads that are immediately outdated & wrong once referenced during discussion & development that follows.

2) A User Story frames project requirements around the user, whereas a Use Case frames its language around systems & components. That's largely a semantic shift & thought exercise more than truly a procedural difference - the end result is similar.

More detail:

The end result in either case is essentially the same - a detailed collection of requirements that are as unambiguous as possible, to be worked on during the next development cycle to completely implement those features. Either Use Cases or User Stories (or Epics) can be used to frame & define features at a high level or a very low level, with detail added as you work from architecture down to implementation.

The key difference is who discusses the details, when, and how much energy they devote to formally capturing the resulting decisions.

With User Stories, they begin quickly as 1-2 lines to simplify & speed initial development, but during sprint planning they still need to be fleshed out in detail for implementation.

I think this is where some confusion might lie: it seems as if "User Stories" are ONLY the short 2-line sound-bites. They're really not - those are just the headlines to what's essentially the same as a detailed Use Case, but written from the User's perspective.

In discussing the User Stories, you still have to answer all the same questions about user-system interactions, boundaries, detailed placement & appearance of interface elements, etc. The key thing is that the removal of ambiguity to determine those specifics is a deliberate, collaborative, verbal group effort. This is similar to Domain-Driven Design where the goal is to achieve a shared vocabulary & understanding of a project so everyone's on the same page.

The details are discussed, decisions get made, and they're captured in a less formal fashion. Sticky notes, sketches, etc - whatever's quick but detailed enough to aid in implementing those stories during that particular sprint. The remaining 1-2-line User Stories hang out in the Backlog waiting to be developed more fully during future sprint planning.

Use Cases, in contrast & at least in my case and the examples I found, seemed to involve the developer working solo to formally capture all the system-level details, interactions, and requirements in a more formal deliverable. There may or may not be any collaborative discussion as you make your best guess. You brainstorm requirements & try to predict obstacles, and see how it pans out later. You learn about the misunderstandings & oversights upon review, after you've spent the time to write everything down & make it look pretty. You might make some silly stick-figure diagrams for some reason. After discussing the Use Cases & addressing any problems, instead of getting to work on the code, you spend time updating the documents so they're pretty and not wrong.

The end result of a formal Use Case is essentially a sequential, formatted, numbered/bulleted-outline description of the exact same feature the User Story's collaborative discussion scribbled down on Post-Its in 1/4 the time.

Licensed under: CC-BY-SA with attribution
scroll top