Using User Stories and Use Cases in the Same Team

agileobject-orientedproject-managementuse-caseuser-story

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:

Use User Stories to define Product Backlog items
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?

Best Answer

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.

Feature Dependencies

You have identified some legitimate limitations of user stories. They are unordered and there is no guarantee they will be independent. In fact, the might be interdependent-- a chicken-and-egg problem. I believe that all non-trivial projects require documentation to supplement the user stories. I watched the agile team here at work create activity diagrams (flow charts) of the business process. These diagrams were used to analyze the feature dependencies. Another approach might be to create PERT diagram in a big all-day session with the customer. In the end, some other artifacts will be necessary to support the user stories.

Epic!

A narrative that describes the scope of a project is a good idea. There should be something like a statement-of-work or a project charter. No serious project should be without one. These documents provide a starting place for identifying user stories. These document help answer tough questions like "What should be the priority of this feature?"

Metadata

After 15 years in the business, I have an opinion about meta-data. In general, it should be avoided. A few reasons include: after a month, no one knows if it is accurate; no one knows if it was updated; it is extra work to create it; you can't predict what metadata will be useful. Most meta-data is a distraction. I like to track owner, author, priority, estimate of effort, and date of last modification. Beyond that, I fight hard to keep meta-data out user stories and use cases.

Benefits (so that...)

I have an opinion about this as well. :-) Including the benefits is vital. Often, users will request a feature without having though about its value. No matter how good an agile team is, the project will fail if it implements unimportant stuff at the expense of more critical functionality. Also as a developer, I do a better job coding a feature if I know how it fits into the big picture. Here is a real-life example of a requirement without justification: "The system shall prevent transactions with EIP and a gift card from occurring.". Huh? What is EIP? Why do I care? Why does anyone care? I don't know. Understanding the context would have been helpful before I went to the business analyst for clarification.

Even worse is when no one remembers why the user story was written. Do we still need this one? Has the business process evolved to the point where this user story is invalid? Does anyone know? These conservations waste time. It gets suckier if the the author of the user story has left the company.

Measurement

Here is an example of user story that is not measurable:

As a Call Center Representative, I want the system to be fast so that customers are not left waiting on the phone.

How fast is fast? A millisecond? A tenth of a second? Ten seconds? Nobody knows. Nobody wants to be wrong so no one every even makes a guess.

Compare that user story to this one:

As a Call Center Representative, I want customer search to return the results in 2 seconds or less (for average daytime call volumes) so that customers are not left waiting on the phone.

This user story is testable. Average day time call volume can be determined from log files. Performance testing can be conducted to determine if the requirement has been met. Even better, the users and developers have agreed on the success criteria well in advance of the end of the project. Testable requirements are a beautiful thing.

Agile Scrum – Do You Estimate All User Stories in Iteration Zero?

I've never seen anyone estimate the entire product backlog. Typically what happens is that the product backlog is prioritized on an going basis by the Product Owner. Scrum has an ongoing activity known as Backlog Refinement in which the Product Owner and Development Team review Product Backlog Items and add sufficient details to implement the items, estimates, and reorder as necessary (perhaps due to a greater understanding of the complexity or technical dependencies). By Sprint Planning, a good number of Product Backlog Items are refined and the team pulls a sufficient number into the Sprint, based on its priority in the Product Backlog.

The acceptance criteria should be added by the Product Owner before estimation. Since acceptance criteria are based on the business needs (both the functional needs as well as any non-functional or quality attributes associated with the Product Backlog Item), the Product Owner is in the appropriate position to associate these needs with each Product Backlog Item. If there is any additional work that the team feels is necessary to successfully complete the item, they can add it during the discussion of the estimate to ensure that all necessary work is documented and included in the estimate. The team can then include the work necessary to not only complete but also verify and validate the completion of the item in the estimate.

Also, I've never seen a "product burndown chart". The burndown chart is typically for an individual sprint, not for the entire project. On Day 1 of the sprint, the burndown chart reflects the value carried into the sprint. As you implement items from the Sprint Backlog, the chart is updated to reflect the remaining value to implement in the sprint. I don't see why you can't have a product burndown chart based on the refined Product Backlog Item, but as Product Backlog Items are added, refined, and removed, the chart will fluctuate - this should happen far more regularly than changing scope as defined in a Sprint Backlog.