user story estimation

8/9/2019 User Story Estimation

1/44

Writing Effective UserStories


2/44

The Scrum Rituals


3/44


4/44


5/44

STOCKINGBACKLOG

O PO develops in collaboration with

stakeholders

O Product Roadmap may drive themes & epics

O Items at top fit into a sprint

O Whole backlog indicates direction

O Never done, evolves over time


6/44

GROOMINGBACKLOG

Whole-team collaboration

Right-size items

Define major acceptance criteria

Assign size

Always on-going and evolving


7/44

The Daily Scrum/Standup Rules:

O Daily, 15-minute synch-up

O Same time, same place

O Stand-up, no problem solving

Answer the 3 questions:O What did you do yesterday?

O What do you commit to do today?

O Are you blocked?

Impediments = SMs Task List

Note the Decisions Stakeholders are invited to observe but cant

talk:O Take issues to ScrumMaster/Manager after the Standup has ended


8/44

First things firstO Scrum Master facilitates

O Prioritize the featuresProduct Owner /

Business Owner along with the technical lead

O User StoriesTechnical Lead along with the

team

There are several ways to prioritize the requirements in

the backlog. Some of the most popular ones include,

MoSCoW

O M - MUSThave this.

S - SHOULDhave this if at all possible.

C - COULDhave this if it does not affect anything

else.W - WON'Thave this time but would like in the

future.

Each requirement will have the priority which would be

tagged to MSCW. M being the highest and W being

the lowest.


9/44

Whats a User Story?


10/44

So what really is a User Story?O User stories are very slim and high-level

requirements artifacts

O User stories are oriented to reflect the desires

of the end user, they help developers remain

focused on the customer.


11/44

User Story Vs Spec DocUser stories offer a quick way of handling customer requirements without having

to create formalized requirement documents and without performing

administrative tasks related to maintaining them. A project will gather user stories

in order to respond faster and with less overhead to rapidly changing real-world

requirements. Flexibility & Satisfaction.


12/44

INVESTing in a Good Story


13/44

INVESTing in a Good StoryThe INVEST criteria are Independent, Negotiable, Valuable, Estimatable, Small(sized appropriately), and Testable

Independent

O As much as is practical, user stories should be independent or at least onlyloosely coupled with one another.

Negotiable

O Stories are not a written contract. they leave room for the product owner, thestakeholders, and the team to negotiate the details

Valuable (Serve a purpose)

O Stories need to be valuable to a customer, user, or both. Technical Stories canexist, provided it delivers value ultimately

Estimatable & Small (Achievable)

O Its hard, if not impossible, to plan sprints around stories that are too bigTestable (Specific)

O Without a clear idea of how to prove the doneness of a story, its almostguaranteed that the PO and the Scrum Team will not be seeing the story in thesame light.


14/44

What is in a User Story?written description or short titleof the story

used as a token for planning and as a reminder

to have conversations

conversationsabout the story that serve to

flesh out the details of the story

acceptance teststhat convey and

document details and that can be used

to determine when a story is complete


15/44

AS A ,

I WANT TO ,

SO THAT .


16/44

AS A DOG,

I WANT TO BE ABLE TO ORDER FOOD ONLINE,

SO THAT I DONT HAVE TO RELY ON MY LAZY BOSS

ANYMORE.


17/44

Lets Dive DeepTechnical - Who ?Developer & Tester

Clearly articulate the requirement in the below format

As a user (end user)

I want to doxxxxxx (how to do this when this can be done in several diff. ways)

So that I canxxxx (end result achieved) (context)

Example : The dogs online food order portal

Here we are switching the view from the developer to the end user.

So you put yourself in the end users position. Setting the context so that as a team

we can see the bigger picture. In waterfall model people think which piece I have to

deliver.

Ordering onlineGeneric

But who is orderingthe game changer


18/44

Epic & Theme


19/44

User story Abstraction

Hierarchy


20/44


21/44

WHERE ARE THE DETAILS?


22/44

Conditions of satisfaction defined


23/44

Details added in smaller sub stories


24/44

Acceptance Criteria - Quantitative and

SpecificWhy?

Behavior Driven Development (BDD)write minimum code that is required to successfully

complete a feature.

Every line of an acceptance Criteria (business case) should be tested

O Testers will write test cases based on the AC

O Business Criteria

AN Acceptance Criteria

O defines the boundaries for a user story/feature

O help the product owner answer what she needs in order for this feature to provide value

(typically these are the minimum functional requirements)

O

help the team gain a shared understanding of the story/featureO help developers and testers to derive tests

O help developers know when to stop adding more functionality to a story

Now that the minimum code has passeddoes it mean that we are done?


25/44

Definition of DoneO This is where DOD comes into placeCode

should be maintainable, manageable and

follows a standard and to reduce the Cost of

quality

O Size of a story = effort to work a story to DONE

DONE

O Need absolute clarity and agreement

O The more you put into the sprint, the less risk

when you get closer to the release


26/44

Sample Definition of DoneDefinition of Done for a Story

Working software + demoO Unit testO code reviewO Installer

Tests -> testcase + proof of successful run Functional run Functional review by product owner Performance or load testing Regression tests

Documentation + review by PM/MA User docs / online help Design doc (intern use) Samples for critical features Release notes API documentation


27/44

Whats the Risk?O The user story should have all the information that will be needed

to consider the story as complete, without which progress cant be

tracked.

O MVPminimum viable productit is essential that the User story

breakdown gives a clear understanding of the amount/type of work

that is needed and whether it is achievable and whether it will have

an impact on the PSI eventually

O RISK- when the above exercise is not completed effectively, there is

a high chance of identifying critical issues at a point where things

go out of hand and potentially can jeopardize the goal of the

project.


28/44

IceboxO All the Features that dont have user stories /

AC / DOD are isolated and stored for future

Its an imaginary line that we draw to say that

the items below this is not clear and needs to be

broken down


29/44


30/44

Backlogsizing


31/44

we are not good at

estimating


32/44

we are good at

comparison


33/44

Start with a rough size . . .


34/44

. . . then get more specific


35/44

What Sizing Considers . . .O Design technology other considerations

O Code Complexity / Business logic / have

been done before?O Test Manual / Automate / Test

O And???


36/44

What Sizing Considers Complexity

How many moving parts are involved in delivering

This?

Effort

How much effort will it take to get it done?

Doubt

Are there things about this that because we dont yet

know, we are worried about?


37/44

1 2 3 5 8 13

20 40 100


38/44

COUNTRY POINTS

Country Points

Finland

Denmark

USA

China

Austria

Canada

BrazilFrance

India

Germany

Slovakia

Population / Size / Per Capita income


39/44

Sizing Estimating


40/44

PLANNING POKER


41/44

PLANNING POKERO Read user story, discuss briefly

O Each team member selects estimate card

O Cards all turned over at onceO Discuss difference and outliers

O Re-estimate until estimates converge


42/44

Bucketed Relative Sizing


43/44

Team Estimation Game

(aka Bucketing)O Place a story card on the table

O Pick next card and place it relative to the first based on

O size/complexity. Explain.

O For each move thereafter,

o Pick the next card and place it,o Move a card thats already been placed, or

o Pass.

o Explain your move and let the team discuss.

O Continue until there are no more moves to be made.

O Collect into stacks if not already stacked.

O Assign points to each stack.Created by:

Steve Bockman


44/44

Bucketed Relative Sizing

1 53 8 13LS

user story estimation

Documents