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

http://www.youtube.com/watch?v=Miwb92eZaJg

http://www.youtube.com/watch?v=Miwb92eZaJg

Chaotic System-Software Development Environment

Ordered System-Software Development Environment

Complex System-Software Development Environment


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

Five (5) “whys” analysis applied as an effective reflective technique in the world of “being” agile and lean


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

6

Copyright © 2005, Mountain Goat Software


Scrum Framework

7Copyright © 2008 Russell Pannone. All rights reserved.

Scrum Framework•Product owner

•Team

•Scrum Master

Roles

•Sprint planning

•Sprint review

•Sprint retrospective

•Daily scrum meeting

Ceremonies

•Product backlog

•Sprint backlog

•Burndown charts

Artifacts


Scrum Explained


In Scrum you work in iterationsdelivering value-adding results incrementally

“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

9


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

10


1. Performing tasks to complete the story

2. Completing the story based on story acceptance criteria and team's definition of done

11

BusStrategy

BusinessModel

System RequirementsFunctional

&Non-Functional

Solution/IT-Services

Where do Stories

come from

Use Cases


Optional

Optional

Optional

CustomerBusiness PartnerProduct Owner

Characteristics of good stories

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

13

Story1As 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

Story2As 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

Story3As an eligible user, I want to access my record, so that I can verify that it is correct

Story4As an eligible user, I want to access my record and delete any or all of my information to keep it current

Story5As an eligible user, I want to access my record and change any or all of my information to keep it current

Story6As an eligible user, I want multiple payment options to pay fees so that I am able to access the features of the DMV site that require payment

Story13As the application, I want to maintain an audit trail of changes for each eligible user record indicating all edits

Story12As an eligible user, I want to be able find an address for my local DMV office and print the results

Story11As an eligible user, I want to view a list of assembled answers to questions asked most frequently of the DMV


As a <who> I want <what> so that <why>

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

Epic (compound story)

As an eligible user, I want to view , add, change or delete my DMV information so that I can keep it current

14

StoryAs an eligible user, I want to access my record, so that I can verify that it is correct

StoryAs an eligible user, I want to access my record and delete any or all of my information, so that I can keep it current

StoryAs an eligible user, I want to access my 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 whyand 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

18

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 future1. Verify that a payment can be made2. 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 created2. Verify that a user name that is already in use (assigned) is not accepted and the user notified then prompted for a different user

name3. 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 data6. Verify appropriate action is taken if the data entered is invalid7. 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 correct1. Verify that the user’s record is displayed2. 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 accesses4. Verify that the user is limited to three record accesses each year5. Verify that the system displays user profile information including names, addresses, email addresses, credit cards, and PayPal6. Verify that records for any nonresident individual with a driving record in the state can be accessed


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.


Five factors to consider when prioritizing1.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

Priority

Story Points

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

Copyright © 2008 Russell Pannone. All rights reserved.24

Story Sizing Exercise

25

Backup Slides


Work Que (Kanban)

Pending WIP Done

Test

Define

Design

Code

Build & Implement


Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

http://farm1.static.flickr.com/55/147874576_8a453079f3.jpg




















































Technology

Product backlog stories_acceptancecriteria_size_priority