Note that the Product Backlog has Sprint numbers
across the top, so this is an example where the whole backlog has been
planned into Sprints. For most products, there would probably be many
items on the backlog that are not yet planned.
Notice also that the values for each item on the Product Backlog are Fibonacci points represensing the relative size of each feature They do not represent hours.
However on the Sprint Backlog, the numbers across the top are the days in the Sprint, and the values for each task are estimated hours.
These examples are also good at highlighting how the Product Backlog is about Features (or we would use User Stories), whereas the Sprint Backlog breaks those Features into Tasks.
Use cases vs user stories in Agile development
by courtney / January 18, 2012
TL;DR – User stories aren’t use cases. By themselves, user stories don’t provide the details the team needs to do their work. The Scrum process enables this detail to emerge organically (largely), removing the need to write use cases.
A user story is a short description of something that your customer will do when they come to your website or use your application/software, focused on the value or result they get from doing this thing. They are written from the point of view of a person using your website or application, and written in the language that your customers would use.
A user story is usually written using the format canonised by Mike Cohn: As an [actor] I want [action] so that [achievement]. So, for example: As a Flickr member, I want to set different privacy levels on my photos, so I can control who sees which of my photos.
A use case is a description of a set of interactions between a system and and one or more actors (where ‘actor’ can be people, or other systems: for example, both online shoppers and PayPal can be actors). They are usually created as documents, and generally include this kind of information:
use case title
rationale/description/goal
actor/user
preconditions (the things that must have already happened in the system)
standard path or main success scenario (what will usually happen, described as a series of steps)
alternate paths or extensions(variations on the above/edge cases)
post conditions (what the system will have done by the end of the steps).
Notice also that the values for each item on the Product Backlog are Fibonacci points represensing the relative size of each feature They do not represent hours.
However on the Sprint Backlog, the numbers across the top are the days in the Sprint, and the values for each task are estimated hours.
These examples are also good at highlighting how the Product Backlog is about Features (or we would use User Stories), whereas the Sprint Backlog breaks those Features into Tasks.
Use cases vs user stories in Agile development
by courtney / January 18, 2012
TL;DR – User stories aren’t use cases. By themselves, user stories don’t provide the details the team needs to do their work. The Scrum process enables this detail to emerge organically (largely), removing the need to write use cases.
A user story is a short description of something that your customer will do when they come to your website or use your application/software, focused on the value or result they get from doing this thing. They are written from the point of view of a person using your website or application, and written in the language that your customers would use.
A user story is usually written using the format canonised by Mike Cohn: As an [actor] I want [action] so that [achievement]. So, for example: As a Flickr member, I want to set different privacy levels on my photos, so I can control who sees which of my photos.
A use case is a description of a set of interactions between a system and and one or more actors (where ‘actor’ can be people, or other systems: for example, both online shoppers and PayPal can be actors). They are usually created as documents, and generally include this kind of information:
use case title
rationale/description/goal
actor/user
preconditions (the things that must have already happened in the system)
standard path or main success scenario (what will usually happen, described as a series of steps)
alternate paths or extensions(variations on the above/edge cases)
post conditions (what the system will have done by the end of the steps).
