Product backlog stories_acceptancecriteria_size_priority

Delivering value early
and often, giving
ourselves the best
opportunity to beat
the competition to
market, realize
revenue and discover
insights that we can
use to help us improve

Copyright © 2008 Russell Pannone. All rights reserved.

Product Backlog

 Stories at the right level of detail
 Prioritizing stories
 Sizing stories
 Deriving/estimating duration to deliver product
 Committing to schedule to deliver product
Copyright © 2008 Russell Pannone. All rights reserved. 2

How to Organize a Children's Party

 Chaotic System-Software
Development Environment
 Ordered System-Software
 Complex System-Software


Five (5) “whys” analysis applied as an effective reflective
technique in the world of “being” agile and lean
1. Why is our Product Owner, unhappy?
Because we did not deliver the product release and business value when we said
we would
2. Why were we unable to meet the agreed upon timeline or schedule for delivery?
The product took much longer to develop than we thought it would
3. Why did it take so much longer?
Because we underestimated the complexity and uncertainty of the stories
4. Why did we underestimate the complexity and uncertainty?
Because we did not have acceptance criteria associate with each story, our
stories were not at the right level of detail and we did not realistically size each
story prior to committing to a schedule for delivering the release
5. Why didn't we do this?
Because the higher powers were still working under the traditional waterfall
planning mental-model, as a result we felt pressure to work faster and skipped
steps

 Solution: We clearly need to review and improve our approach to writing
stories, prioritizing stories, sizing stories, deriving/estimating duration and
committing to a schedule for delivering the product >>>>> Then get buy-in
and visible support from the higher powers

Scrum Framework

Copyright © 2005, Mountain Goat Software

1. Agile puts the Product Owner (aka “the business” or customer representative) in the
driver’s seat – In the majority of the waterfall style projects the customer is involved, but in a limited capacity. They get
to define a scope up-front, but then any changes they deem necessary are change ordered back to them. This practice
assumes that the customer knows exactly what they want up front and penalizes them for changing their minds later in the
development process.

2. Agile allows the business to quickly react to changing market conditions and needs – The only
thing constant in today’s economy is change. Businesses need to be able to make quick course corrections in order to
survive.

3. Agile provides visibility into the development process – For many customers software development is a
dark art. They don’t have the background in order to understand the technical details and in most cases the development
team prefers it this way. The customer is left feeling helpless and Agile engages them throughout the development
lifecycle, providing enhanced visibility.

4. Agile also puts the Development Team in the driver’s seat - While the Product Owner is responsible
for “what” is to be developed the Development Team is self-directing and self-organizing as to “how” to develop the system-
software product


Roles
•Product owner
Scrum Framework
•Team
•Scrum Master
Ceremonies
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artifacts
•Product backlog
•Sprint backlog
•Burndown charts


Scrum Explained
“The… ‘relay race’ approach to
product development…may conflict
with the goals of maximum speed and
flexibility. Instead a holistic or ‘rugby’
approach—where a team tries to go
the distance as a unit, passing the ball
back and forth—may better serve
today’s competitive requirements.”-
Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development
Game”, Harvard Business Review, January 1986

In Scrum you work in iterations
delivering value-adding results
incrementally


1. Selecting Stories from the
Product Backlog based on
the team’s velocity
2. Identifying the tasks to
realize a selected Story
3. Estimating the level-of-
effort required to
complete the task


1. Performing tasks to
complete the story
2. Completing the story
based on story
acceptance criteria
and team's
definition of done


Where do
Optional
Stories
come from
Optional

Optional
Bus
Strategy

Use Cases
Business
Model

System Requirements
Functional
Customer &
Business Partner Non-Functional

Product Owner
Solution/IT-Services


Characteristics of good stories
As a <who> I want <what> so that <why>
 A good story is negotiable, testable, estimatable, commercially or
operationally value-adding, cohesive and loosely-coupled
 It is not an explicit contract for features or functionality; rather stories
are short descriptions of functionality, the details of which are to be
refined in a conversation between the Product Owner (aka, the business or
customer) and the development team
 The challenge comes in learning to include just enough detail to be able to
prioritize and estimate the size of story and minimize ambiguity
Story1 Story4
As an eligible user, I want to pay the As an eligible user, I want to access my Story11
onetime registration fee of $10, so record and delete any or all of my As an eligible user, I want to view a list
that I can access my driver’s record in information to keep it current of assembled answers to questions
the future asked most frequently of the DMV

Story5
Story2 Story12
As an eligible user, I want to access my
As an eligible user, I want to create a As an eligible user, I want to be able
record and change any or all of my
unique user name and password so find an address for my local DMV
information to keep it current
that my access is limited to my record office and print the results
and to track activity and payment
Story6 Story13
Story3 As an eligible user, I want multiple As the application, I want to maintain
As an eligible user, I want to access my payment options to pay fees so that I an audit trail of changes for each
record, so that I can verify that it is am able to access the features of the eligible user record indicating all edits
correct DMV site that require payment

Story Size
 The fact of the matter is some stories can be too big,
some can be too small, and some can be just right
 Stories that are too big are called Epics
 Epics are difficult to work with because they frequently
contain multiple stories
 Epics typically fall into one of two categories:
 The compound story
 The complex story Story
record, so that I can verify that it is

Epic (compound story)
correct

As an eligible user, I
Story

want to view , add,
record and delete any or all of my
information, so that I can keep it

change or delete my
current

DMV information so that Story

I can keep it current record and change any or all of my
information, so that I can keep it
current

Complex Story
 Unlike the compound story, the complex story is a story that is inherently
large and cannot easily be disaggregated into a set of constituent stories
 If a story is complex because of uncertainty associated with it, you should
estimate the size of the story at the highest range of your estimating scale
(1, 2, 3, 5, 8, 13, 21, 34)
 Then prior to the sprint where you are going to pull it in have an
investigate story to more clearly understand what the solution involves to
deliver this story
Epic (complex story)
As an eligible user, I want multiple payment options to pay my fees so that
I am able to access the features of the DMV site that require payment
For example, suppose the team is given the story depicted above, but none of the
developers has ever done credit card processing before. The team would then decide
to disaggregate the story like this:
• Investigate credit card processing over the web
• A user can pay with a credit card
In this case the first story will send one or more developers on a spike. When complex
stories are split in this way, always define a time-box around the investigative story, or
spike.

Meeting the Product Owner’s Conditions-of-Satisfaction
 Outside-In-Design > One of the key characteristics that make stories so fitting for
delivering value early and often is that they focus on describing the source of value to
the Product Owner, instead of the mechanics of how that value is delivered
 Stories strive to convey the Product Owner wants and needs, the who, what and why
and not the specifics of the solution or the details about how the team will implement
the story

 Acceptance criteria is used at the end of a Sprint/Iteration, when demonstrating to the
Product Owner what the team has implemented
 Acceptance criteria is used to guide the team’s definition of “done” for a story
 A story is not considered complete or “done” until the acceptance
criteria/conditions-of-satisfaction have passed

Acceptance Criteria
 Acceptance criteria, represents the details for a story and specifies
the desired behavior and functionality the system-software must
implement
 Acceptance criterion is high level tests to verify and validate the
completeness of a story or stories implemented during a
Sprint/Iteration, expressed in a business domain language
 These tests are created ideally through collaboration between
business customers, business analysts, testers and developers;
however the Product Owner (aka, the business or customer) is the
primary owner of these conditions-of-satisfaction


Formulating Acceptance Criteria
 We should try to formulate acceptance criteria in terms of the goal of the
story and leave the solution up to the developers and the Product Owner to
decide and discuss at a later time, during Sprint Planning and a Sprint;
when we’re validating and verifying the acceptance criteria and
implementing the story itself
As an eligible user, I want to pay the onetime registration fee of $10, so that I can access my driver’s record in the future
1. Verify that a payment can be made
2. Verify that once a payment is made, the user can view their record (with any subsequent fees)
3. Verify that payment option is not available if registration has already been paid

As an eligible user, I want to create a unique user name and password so that my access is limited to my record and to track activity and
payment
1. Verify that a user account can be created
2. Verify that a user name that is already in use (assigned) is not accepted and the user notified then prompted for a different user
name
3. Verify that the user name conforms to naming convention (length, caps, etc.)
4. Verify that the password conforms to naming convention (length, caps, symbols, etc.)
5. Verify the generation of correct error messages when the user attempts to enter invalid data
6. Verify appropriate action is taken if the data entered is invalid
7. Verify that the legal compliance conditions and consequences of use are displayed and accepted

As an eligible user, I want to access my record, so that I can verify that it is correct
1. Verify that the user’s record is displayed
2. Verify that the user cannot access records other than his/her own (or dependents)
3. Verify that user is charged $10 for the first access and $5 for subsequent accesses
4. Verify that the user is limited to three record accesses each year
5. Verify that the system displays user profile information including names, addresses, email addresses, credit cards, and PayPal
6. Verify that records for any nonresident individual with a driving record in the state can be accessed

 Depiction of the user
interface or maybe even a
report layout, is just as
much a part of the details
behind a story as
acceptance criteria
 Wireframes and screen
mockups are often
attached to stories as a
basic visual guide used in
interface design by the
development team
 Low fidelity diagrams
depicting a candidate
solution may also be
attached to stories to
visually communicate its
design Copyright © 2008 Russell Pannone. All rights reserved. 19

Five factors to consider when prioritizing
1.The commercial or operational value of the delivered story
2.Degree of uncertainty - the amount and significance of learning and new
knowledge gained by developing the story; focused on requirements
and technology
3.The amount of risk removed by developing and delivering the story –
focused on schedule, budget, scope, operation, technology
4.Dependencies – stories that must be developed together and are
delivered together to provide value to the customer
5.The cost of developing and delivering the story
20

Story Prioritizing Exercise

21

User Stories Business Story Points
Priority
Story A 1 5
Story B 2 8
Story C 3 1
Story D 4 8
Story E 5 2
Story F 6 2
Story G 7 2
Story H 8 8
Story I 9 5
Story J 10 1

Copyright@ 2008 Russell Pannone. All rights reserved. 22

Story Points: Relative Measure of
the Size of a Story

23

24

Story Sizing Exercise

25

Work Que (Kanban)
Pending WIP Done
Story Story
Story
Story Story
Story
Define Story
Story Story Story
Story
Story Story

Story
Story Story Story
Story Story
Story
Story Build & Story
Test Design
Implement
Story Story
Story Story

Story Story Story

Story
Story

Story
Story Story
Code
Story Story


Product backlog stories_acceptancecriteria_size_priority

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Product backlog stories_acceptancecriteria_size_priority

Similaire à Product backlog stories_acceptancecriteria_size_priority (20)

Plus de Russell Pannone

Plus de Russell Pannone (14)

Dernier

Dernier (20)

Product backlog stories_acceptancecriteria_size_priority