Contenu connexe Similaire à Product backlog stories_acceptancecriteria_size_priority Similaire à Product backlog stories_acceptancecriteria_size_priority (20) Plus de Russell Pannone (14) Product backlog stories_acceptancecriteria_size_priority1. 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.
2. 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
4. Chaotic System-Software
Development Environment
Ordered System-Software
Development Environment
Complex System-Software
Development Environment
Copyright © 2008 Russell Pannone. All rights reserved. 4
5. 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
Copyright © 2008 Russell Pannone. All rights reserved. 5
6. 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
Copyright © 2008 Russell Pannone. All rights reserved. 6
8. 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
Copyright © 2008 Russell Pannone. All rights reserved. 8
9. 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
Copyright © 2008 Russell Pannone. All rights reserved. 9
10. 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
Copyright © 2008 Russell Pannone. All rights reserved. 10
11. 1. Performing tasks to
complete the story
2. Completing the story
based on story
acceptance criteria
and team's
definition of done
Copyright © 2008 Russell Pannone. All rights reserved. 11
12. 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
Copyright © 2008 Russell Pannone. All rights reserved. 12
13. 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
Copyright © 2008 Russell Pannone. All rights reserved. 13
14. 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
As an eligible user, I want to access my
record, so that I can verify that it is
Epic (compound story)
correct
As an eligible user, I
Story
As an eligible user, I want to access my
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
As an eligible user, I want to access my
I can keep it current record and change any or all of my
information, so that I can keep it
current
Copyright © 2008 Russell Pannone. All rights reserved. 14
15. 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.
Copyright © 2008 Russell Pannone. All rights reserved. 15
16. 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
Copyright © 2008 Russell Pannone. All rights reserved. 16
17. 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
Copyright © 2008 Russell Pannone. All rights reserved. 17
18. 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
Copyright © 2008 Russell Pannone. All rights reserved. 18
19. 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
20. 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
Copyright © 2008 Russell Pannone. All rights reserved.
20
22. 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
23. Story Points: Relative Measure of
the Size of a Story
Copyright © 2008 Russell Pannone. All rights reserved.
23
28. 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
Copyright © 2008 Russell Pannone. All rights reserved.