Loading presentation...

Present Remotely

Send the link below via email or IM


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.


User Story Creation & Estimation

No description

Peter LePiane

on 23 May 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of User Story Creation & Estimation

User Story Creation & Estimation
Why User Stories for Requirements?
Writing User Stories
Estimating User Stories
What's the issue with Existing Requirements methods?
We can't know everything in advance
Extra detail mistaken for accuracy &/or precision
Solutions on autopilot
The product shall have a gas powered engine
The product shall have 4 wheels
The product shall have a rubber tire mounted to each wheel
The product shall have a steering wheel
The product shall have a steel body
The solution is what the developer interpreted
Users are not engaged participants
What does this describe??
Developers must be able to estimate (or guess at) the story size or amount of time it will take to turn it into a working part of the solution
If a story can't be tested, how will you know when it is done?
What makes a good User Story?
Valuable to user/customer
If not, then challenging to prioritize and plan

As a user I can pay with Visa
As a user I can pay with MC
As a user I can pay with AmEx

Suppose estimate is that it will take 3 story points to implement one CC and 1 to implement each additional.

Which story gets 3 points?
User Story is NOT a contract

It is a reminder to hold a conversation/negotiation between the user and the solution developer to determine the details of a piece of functionality
A User Story does not document requirements,
it represents them
​Stories represent discrete and valuable functionality that a user would perform in a single setting

BEST way to ensure stories are valuable to users/customers is for them to write them
Anatomy of a User Story
The Story Writing Workshop
If the requirements don't state that "The System shall ..." then it must be assumed that "The System shall not ..."

How to tell if a requirement is intentionally missing or not?
What if the story is not estimatable because it is based on technology that is not understood?
Spike it!!
Spike = An experiment to learn just enough to be able to estimate
An unestimatable story turns into one spike story + the original story
Acceptance Criteria = "A user must never wait long for a screen to appear"
Acceptance Criteria = "New screens appear within 2 seconds in 95% of all cases"
Acceptance Criteria = "A new user must find the system easy to use"
Acceptance Criteria = "A new user can complete the run payroll workflow without training"
Expectations go here:

"Test for failed payment with expired CC"

"Test that 'Salary' label doesn't appear if no Salary of job"
Product Vision
Write Stories
User Roles
Elevator Pitch
Design the Box
Product Pinocchio
30 minutes to:
(5) Invent (or select) a Product
(3/element) - Brainstorm ideas for the 7 elements keeping in mind the Elevator Pitch formula
(5) - Try out different Elevator Pitches & select the best one

Assume a role!!
20 minutes to:
(15) Design the box for the product
(5) Present/Sell the product in the box

Switch roles!!
35 Minutes to:
(10) Draw the character that is the product
(5) What am I like?
(5) What are my values?
(5) What is my community?
(5) What makes me different?
(5) What is my fight?

Switch roles!!
Role Modeling
25 minutes to:
(10) Write & post role names
(5) Organize roles by overlapping & grouping
(5) Consolidate roles
(3) Final grouping of roles

Assume roles!!
Empathy Map
15 minutes for each Role to:
(10) Brainstorm & post to each category FROM THE ROLE'S POINT OF VIEW
(5) Synthesize by completing the "Wants" & "Motivations" sections

Switch roles!!
High-Level Prototype
Select 2 Roles to explore

20 minutes for each Role to:
(10) Build H-L Prototype
(10) Write User Stories from H-L Prototype

Switch roles!!

Concentrate on quantity not quality & NO JUDGEMENT! The point is NOT solution design. Use the Parking Lot.
Wideband Delphi
5 minutes for each User Story to:
i - (1) Customer selects a story at random
ii - (1) Designer & Developer estimate
iii - (2) If estimates differ:
Designer & Developer explain their estimates
Designer & Developer estimate again
iv - (1) If estimates have not converged, return to ii
v - Write estimate on card and post it in the estimate matrix

Estimate 6 different stories

Customer = Geoff, Designer = Tegan, Developer = David

Story Point = 1 ideal day of work
10 minutes to:
Examine each column to ensure similar sizing
Examine across columns to ensure accurate relativity
Discuss & revise estimates as necessary

Maintain roles
What's next?
Write a Fixed Price per Story Point proposal
Profitable Price per Story Point = ??? - will only improve with time
Implement "Exchange Requests"
Provide ability to "buy" Story Points at the same rate

Release Plan (Customer + Developer)
Customer prioritizes stories
Customer & Developer select Iteration length
Establish Initial Velocity (# actual days in an ideal day)
Allocate stories to Iterations

Iteration Plan (Customer + Developer)
Just-in-time architecture & software design
Discuss each story to:
Break it into tasks
Assign responsibility for each task
Estimate each task (in ideal days)
What's next?
Run Iterations!
Daily stand-up meetings
Track Velocity
Monitor burndown

Continuously improve
Conduct retrospectives
Modify the process as necessary
Full transcript