Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Writing Good User Stories

Teaches key concepts about user stories
by

Jill Henry

on 16 March 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Writing Good User Stories

An agreed-upon Definition of Done is
essential to working Agile! Defined by the team adhering to department or organizational standards
Reviewed periodically for updates
Reviewed during sprint planning to ensure all elements are accounted for Acceptance Testing Built from acceptance criteria, acceptance tests are not functional tests, instead, they are the conditions of satisfaction being placed on the system. The team writes these in collaboration with the Product Owner, representing what needs to pass for the PO to accept the story. Functional and unit tests go much deeper in testing all functional flows, exception flows, boundary conditions, and related functionality associated with the story To Do In Progress Done What is a
User Story? Writing
User Stories Slicing
the Cake When is a
Story Done? Task Board comes from
XP carries the
value stream
to the user all about the
user's goals the workhorse
in agile
development story
template INVEST Acceptance
Criteria 3 C's what is it? why is it
important? how to do it example done when acceptance
tests pass meets team's
definition
of done To Do In Progress Done What is a
User Story? Writing
User Stories Slicing
the Cake When is a
Story Done? Task Board comes from
XP carries the
value stream
to the user all about the
user's goals the workhorse
in agile
development story
template INVEST Acceptance
Criteria 3 C's what is it? why is it
important? how to do it example acceptance
tests pass meets team's
definition
of done As a <role>,
I want <activity>,
so that <business value>. Role: types of users. Who will be using your system? These can be internal users, external customers, another system - whoever is the final consumer of the story. Activity: what the user wants out of the system. Business value: since stories are the vehicle for
delivering the value stream to the user, we describe
the value directly in the story. This reminds the team
why the story is important and provides context. As a recruiter, I can
manage job ads I've placed. To Do In Progress Done What is a
User Story? Writing
User Stories Guidelines for Good Stories When is a
Story Done? Task Board comes from
XP carries the
value stream
to the user all about the
user's goals the workhorse
in agile
development story
template INVEST
in a good
story Acceptance
Criteria 3 C's Slice
the
Cake Start with
Goal Stories Write Closed
Stories Put
Constraints
on Cards acceptance
tests pass meets team's
definition
of done Independent
Negotiable
Valuable
Estimatable
Small
Testable Independent As a recruiter,
I can pay for a job posting
with a Visa card. As a recruiter,
I can pay for a job posting
with a Mastercard. As a recruiter,
I can pay for a job posting
with an American Express card. As a recruiter,
I can pay for a job posting
with a credit card. Note: support Visa, MC, and Amex As a recruiter,
I can pay for a job posting
with one type of credit card. As a recruiter,
I can pay for a job posting
with two additional types of credit cards. Negotiable short descriptions of functionality
details should be negotiated between customer and dev team
state the user's goal, not the solution, to avoid constraining the various ways the problem could be solved from the start Valuable connections to the database
should be managed through
a connection pool As an Administrator,
I want to support up to 50 users
with only a five-user database license
so that I can keep licensing costs to a minimum Estimatable 3 reasons stories may not be estimatable
team lacks domain knowledge
team lacks technology knowledge
story is too big As a user, I want access to
the legacy system to be transparent,
so that I don't have to know how to
access two different systems. Spike: timeboxed experiment
to learn how to integrate with
the legacy system. Small As a job seeker, I want to
find a jobthat matches my
skills and experience. Stories can be too big if they are:
epics
complex
compound Testable As a salesperson, I want my
contacts to be returned within
three seconds and to display only
contacts that match my search critieria. As a salesperson, I want relevant
contacts to be returned quickly. captures agreement between team
and Product Owner on when the story
will be accepted As a job seeker, I want to be
able to create a resume and save it with name
so that I can respond to job postings with
a resume tailored to the position. Note: include name, address, professional and educational history.
Note: require that resume name is unique. Acceptance Criteria
User can create a resume
User can enter a resume name from 1-20 characters in length
User can enter name, address, professional history, and educational history
User can successfully save resume card
conversation
confirmation start with goal of finding a job, then:
search for jobs she's interested in
automate the search process so that she doesn't have to search manually every time
make her resume available so that employers may find her
easily apply for jobs she likes
These goals can now be turned into epics, and further decomposed into stories As a recruiter, I can review resumes
from an applicant to one of my ads. A recruiter, I can change the
expiration date of an ad. Slice the cake by including a little from each architectural layer. This will:
reduce the risk of finding issues when integrating layers
if the slice provides enough value, it could potentially be released A closed story is one that finishes with the achievement of a meaningful goal and that allows the user to feel she has accomplished something. this activity is never complete As a recruiter, I can delete an
application that is not a good match for a job. As a <role>,
I want <activity>,
so that <business value>. Role: types of users. Who will be using your system? These can be internal users, external customers, or anyone who will be using your system. Activity: what the user wants out of the system. Business value: since stories are the vehicle for
delivering the value stream to the user, we describe
the value directly in the story. This reminds the team
why the story is important and provides context. To Do In Progress Done What is a
User Story? Writing
User Stories Guidelines for Good Stories When is a
Story Done? Task Board comes from
XP carries the
value stream
to the user all about the
user's goals the workhorse
in agile
development story
template INVEST
in a good
story Acceptance
Criteria 3 C's Slice
the
Cake Start with
Goal Stories Write Closed
Stories Put
Constraints
on Cards acceptance
tests pass meets team's
definition
of done Independent
Negotiable
Valuable
Estimatable
Small
Testable Independent As a recruiter,
I can pay for a job posting
with a Visa card. As a recruiter,
I can pay for a job posting
with a Mastercard. As a recruiter,
I can pay for a job posting
with an American Express card. As a recruiter,
I can pay for a job posting
with a credit card. Note: support Visa, MC, and Amex As a recruiter,
I can pay for a job posting
with one type of credit card. As a recruiter,
I can pay for a job posting
with two additional types of credit cards. Negotiable short descriptions of functionality
details should be negotiated between customer and dev team
state the user's goal, not the solution, to avoid constraining the various ways the problem could be solved from the start Valuable connections to the database
should be managed through
a connection pool As an Administrator,
I want to support up to 50 users
with only a five-user database license
so that I can keep licensing costs to a minimum Estimatable 3 reasons stories may not be estimatable
team lacks domain knowledge
team lacks technology knowledge
story is too big As a user, I want access to
the legacy system to be transparent,
so that I don't have to know how to
access two different systems. Spike: timeboxed experiment
to learn how to integrate with
the legacy system. Small As a job seeker, I want to
find a jobthat matches my
skills and experience. Stories can be too big if they are:
epics
complex
compound Testable As a salesperson, I want my
contacts to be returned within
three seconds and to display only
contacts that match my search critieria. As a salesperson, I want relevant
contacts to be returned quickly. captures agreement between team
and Product Owner on when the story
will be accepted As a job seeker, I want to be
able to create a resume and save it with name
so that I can respond to job postings with
a resume tailored to the position. Note: include name, address, professional and educational history.
Note: require that resume name is unique. Acceptance Criteria
User can create a resume
User can enter a resume name from 1-20 characters in length
User can enter name, address, professional history, and educational history
User can successfully save resume card
conversation
confirmation As a <role>,
I want <activity>,
so that <business value>. Role: types of users. Who will be using your system? These can be internal users, external customers, or anyone who will be using your system. Activity: what the user wants out of the system. Business value: since stories are the vehicle for
delivering the value stream to the user, we describe
the value directly in the story. This reminds the team
why the story is important and provides context. As a job seeker, I can fill out a resume form To Do In Progress Done What is a
User Story? Writing
User Stories Guidelines for Good Stories When is a
Story Done? Task Board comes from
XP carries the
value stream
to the user all about the
user's goals the workhorse
in agile
development story
template INVEST
in a good
story Acceptance
Criteria 3 C's Information on a resume form can be written to the database Slice
the
Cake Start with
Goal Stories Write Closed
Stories Put
Constraints
on Cards acceptance
tests pass meets team's
definition
of done Independent
Negotiable
Valuable
Estimatable
Small
Testable Independent As a recruiter,
I can pay for a job posting
with a Visa card so that Visa
cardholders can purchase
postings. As a recruiter,
I can pay for a job posting
with a Mastercard so that
Mastercard holders can purchase
postings. As a recruiter,
I can pay for a job posting
with an American Express card,
so that AmEx card holders can
purchase postings. As a recruiter,
I can pay for a job posting
with a credit card so that
credit card holders can purchase postings. Note: support Visa, MC, and Amex As a recruiter,
I can pay for a job posting
with one type of credit card so that some credit card
holders can purchase postings. As a recruiter,
I can pay for a job posting
with two additional types of credit cards so that additional credit card holders can purchase postings. Negotiable story author should provide short descriptions of functionality, especially if author is customer or Product Owner
details should be negotiated between customer and dev team and can be captured by refining the story or adding notes
state the user's goal, not the solution, to avoid constraining the various ways the problem could be solved from the start Valuable connections to the database
should be managed through
a connection pool As an Administrator,
I want to support up to 50 users
with only a five-user database license
so that I can keep licensing costs to a minimum Estimatable 3 reasons stories may not be estimatable:
team lacks domain knowledge
team lacks technology knowledge
story is too big As a user, I want access to
the legacy system to be transparent,
so that I don't have to know how to
access two different systems. Spike: timeboxed experiment
to learn how to integrate with
the legacy system. Small As a job seeker, I want to
find a jobthat matches my
skills and experience. Stories can be too big if they are:
epics
complex
compound
If this is the case, break them down Testable As a salesperson, I want my
contacts to be returned within
three seconds and to display only
contacts that match my search critieria. As a salesperson, I want relevant
contacts to be returned quickly. captures agreement between team
and Product Owner on when the story
will be accepted As a job seeker, I want to be
able to create a resume and save it with a name
so that I can respond to job postings with
a resume tailored to the position. Note: include name, address, professional and educational history.
Note: require that resume name is unique. Acceptance Criteria
User can create a resume
User can enter a resume name from 1-20 characters in length
User can enter name, address, professional history, and educational history
User can successfully save resume card
conversation
confirmation split along technical lines, neither is valuable by itself instead, write replacements that provide some end-to-end functionality A job seeker can submit a resume
which includes only name, address,
and most recent job experience. A job seeker can submit a resume
which includes name, address,
educational history, and work history. annotate a story with any constraint that must be obeyed rather than implemented
the new system must use the existing database
the system must support Windows XP and Windows 7
the system will achieve uptime of 99.999% instead: assume that it takes some work to support using a credit card, and then just a minimal amount of work to support additional cards
with that in mind, the stories above have a lot of overlap; for which story would you write the basic credit card implementation? Estimating becomes difficult (which story gets the larger estimate?) one option is to combine these stories into one to eliminate dependencies
this works if the stories are small enough that combining them can still fit into a sprint another option is to make the story credit card-agnostic
the first story will cover the core implementation and the two remaining stories will cover the increments of adding new cards
this allows the team to size each story appropriately 95% of epics and stories should be user facing not technical
rephrasing technical stories with the user and business value listed explicitly provides context for 'why' we are doing something and helps inform how this story should be prioritized
if we can't identify the users or the value, why are we doing it? In this case, the team doesn't have the technical knowledge to be able to estimate access to the legacy system. Solution: do a technical research spike to learn, then estimate the actual stories this story is huge
the bigger it is, the more difficult it is to get an estimate in the ballpark
so break it down to 'right-sized' stories: can fit in a sprint, a couple of days worth of work why is this story untestable? the words 'relevant' and 'quickly' are too ambiguous Everything I know I learned from Mike Cohn :)
Full transcript