Send the link below via email or IMCopy
Present to your audienceStart 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.
Make your likes visible on Facebook?
Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.
User Story Creation & Estimation
Transcript of 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 = 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"
Design the Box
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
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?
25 minutes to:
(10) Write & post role names
(5) Organize roles by overlapping & grouping
(5) Consolidate roles
(3) Final grouping of roles
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
Select 2 Roles to explore
20 minutes for each Role to:
(10) Build H-L Prototype
(10) Write User Stories from H-L Prototype
Concentrate on quantity not quality & NO JUDGEMENT! The point is NOT solution design. Use the Parking Lot.
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
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)
Daily stand-up meetings
Modify the process as necessary