Johanna Rothman Agile Estimation: The Good, The
FD
Published · 26 slides · 0 views
1 / 1
Description
Johanna Rothman Agile Estimation: The Good, The Bad, and The Ugly Chapter 10 Copyright 2017 Estimation is about setting expectations Rothman thats a gross estimate, an order-of-magnitude estimate. Thats the kind of estimate your
Related Topics
Share
Embed code
Download this presentation From Below
"Johanna Rothman Agile Estimation: The Good, The" is the property of its rightful owner. Permission is granted to download and print the materials on this website for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Presentation Transcript
01
Johanna Rothman Agile Estimation: The Good, The Bad, and The Ugly Chapter 10 Copyright © 2017<br>
02
“Estimation is about setting expectations” Rothman
“… that’s a gross estimate, an order-of-magnitude estimate.
That’s the kind of estimate your managers want when they ask you for an estimate.
Those estimates are accurate, but not necessarily precise.”
Dictionary definition of an estimate:
“a rough calculation of the value, number, quantity, or extent of something.
synonyms: estimate, approximation, rough calculation, rough guess, evaluation”<br>
“… that’s a gross estimate, an order-of-magnitude estimate.
That’s the kind of estimate your managers want when they ask you for an estimate.
Those estimates are accurate, but not necessarily precise.”
Dictionary definition of an estimate:
“a rough calculation of the value, number, quantity, or extent of something.
synonyms: estimate, approximation, rough calculation, rough guess, evaluation”<br>
03
Cycle time Teams can provide an accurate estimate if they understand their current reality (what the code looks like), their typical speed (velocity and/or cycle time)”
Cycle Time (Chapter 12, page 185)
The duration of time from when you put a card in the first in-progress column until when you mark the card as “done”.
Cycle Time measures the time the team works on the story”<br>
Cycle Time (Chapter 12, page 185)
The duration of time from when you put a card in the first in-progress column until when you mark the card as “done”.
Cycle Time measures the time the team works on the story”<br>
04
Understand Velocity Product Backlog contains Features and stories for each feature
Stories are estimated in “story points” … each story point representing the team’s assessment of the relative difficulty in designing and implementing a user need
Design and development work is carried out in “Sprints”
Each “Sprint” (timebox) is a specific number of weeks
The team estimates the number of stories they expect to be able to design and development in each “Sprint” … i.e. finish – meaning “Done”
When all “stories” in the Product Backlog are “Done”, the Feature is considered to be “done” … i.e. implemented<br>
Stories are estimated in “story points” … each story point representing the team’s assessment of the relative difficulty in designing and implementing a user need
Design and development work is carried out in “Sprints”
Each “Sprint” (timebox) is a specific number of weeks
The team estimates the number of stories they expect to be able to design and development in each “Sprint” … i.e. finish – meaning “Done”
When all “stories” in the Product Backlog are “Done”, the Feature is considered to be “done” … i.e. implemented<br>
05
Assessing Story size Product Owner creates stories for each feature
… real stories so that the team can understand who the users are and what the intended value is for each story
Relative sizing… using the Fibonacci sequence (1, 2, 3, 8, 13 …)
Smallest stories are sized as 1, the next sized at 2, etc.
See Mike Cohn’s “Planning Poker” video
Advice:
“If you have stories larger than an 8, size up to 13…”
Note: no one understands the amount of work required to design and develop any story size greater than 13 story points<br>
… real stories so that the team can understand who the users are and what the intended value is for each story
Relative sizing… using the Fibonacci sequence (1, 2, 3, 8, 13 …)
Smallest stories are sized as 1, the next sized at 2, etc.
See Mike Cohn’s “Planning Poker” video
Advice:
“If you have stories larger than an 8, size up to 13…”
Note: no one understands the amount of work required to design and develop any story size greater than 13 story points<br>
06
Assessing Story size Large stories have many unknowns… complex
Use a “spike” to determine how you can break the story into smaller, more “manageable stories
Guidelines:
If a story point is larger than the estimated amount of work that the team estimated they could complete in one Sprint, split the story into multiple, smaller stories
Typically requires collaboration with the Product Owner in “breaking” such epic stories into a set of smaller stories
Again: the larger the number of per-story story points, the greater the estimate’s uncertainty!<br>
Use a “spike” to determine how you can break the story into smaller, more “manageable stories
Guidelines:
If a story point is larger than the estimated amount of work that the team estimated they could complete in one Sprint, split the story into multiple, smaller stories
Typically requires collaboration with the Product Owner in “breaking” such epic stories into a set of smaller stories
Again: the larger the number of per-story story points, the greater the estimate’s uncertainty!<br>
07
Story Points The team should learn what it can do in a certain amount of time…
In the SCRUM world the Product Backlog is comprised of Features with each Feature defined by a set of stories.
A set of Feature stories is selected for each Sprint Backlog
Recall the 3-C’s associated with the preparation for the work within the Sprint
Card (identifying the Feature and one specific Feature Story),
Conversation (with Product Owner) and
Confirmation (that the team understands what design and development “tasks” are needed for each Story)<br>
In the SCRUM world the Product Backlog is comprised of Features with each Feature defined by a set of stories.
A set of Feature stories is selected for each Sprint Backlog
Recall the 3-C’s associated with the preparation for the work within the Sprint
Card (identifying the Feature and one specific Feature Story),
Conversation (with Product Owner) and
Confirmation (that the team understands what design and development “tasks” are needed for each Story)<br>
08
Consider Cycle Time to Create More Accurate Estimates DEFINITION: The duration of time from when you put a story in the in-progress column until when you mark the card as “done” (slide 3)
Cycle time should help to improve your estimates of story size
… and help improve your estimates of different sized stories
Rothman’s advice
Take two to four weeks for your initial measurement period… actually, it may take two or more sprints worth of cycle time data to commit to a set of stories that will get “done” at the end of the sprint<br>
Cycle time should help to improve your estimates of story size
… and help improve your estimates of different sized stories
Rothman’s advice
Take two to four weeks for your initial measurement period… actually, it may take two or more sprints worth of cycle time data to commit to a set of stories that will get “done” at the end of the sprint<br>
09
Cycle Time Estimation examples<br>
10
Know the Purpose of Your Estimation “In agile approaches, we can use the team’s wisdom to create accurate estimates, up to a point.”
Managers need gross estimates to understand roughly when they could plan on have a feature set available…
The Team wants to predict the capacity to understand how much it can bring into an iteration
(Here, capacity is the estimated number of story points worth of work that can be “done” in the sprint)
If ???
the team is able to create roughly the same size stories, you do not need to estimate anything at all… You count stories<br>
Managers need gross estimates to understand roughly when they could plan on have a feature set available…
The Team wants to predict the capacity to understand how much it can bring into an iteration
(Here, capacity is the estimated number of story points worth of work that can be “done” in the sprint)
If ???
the team is able to create roughly the same size stories, you do not need to estimate anything at all… You count stories<br>
11
The benefits of the team counting stories… Value to the user of the product…
The team creates and accepts stories of roughly the same size
The team creates stories that tend to become smaller over time, approaching one day or even less
The entire team understands stories across the product
“Consider counting stories for your estimates”
???
Page 155<br>
The team creates and accepts stories of roughly the same size
The team creates stories that tend to become smaller over time, approaching one day or even less
The entire team understands stories across the product
“Consider counting stories for your estimates”
???
Page 155<br>
12
Create Approximate Estimates for Management ??? Many managers are accustomed to thinking about when “all” the features will be done…
… not seeing value before the product is done
How do you estimate when “all” will be done?
Rothman’s approach to estimating “all” the features:
Have the team take all the details about all the features
Use whatever relative sizing approach you prefer
Walk through the roadmap, estimating as you go
Count larger features… the larger the feature, the more estimation uncertainty
Add up your relative estimate (points or cycle time)
Add up the large features so you understand your relative confidence level<br>
… not seeing value before the product is done
How do you estimate when “all” will be done?
Rothman’s approach to estimating “all” the features:
Have the team take all the details about all the features
Use whatever relative sizing approach you prefer
Walk through the roadmap, estimating as you go
Count larger features… the larger the feature, the more estimation uncertainty
Add up your relative estimate (points or cycle time)
Add up the large features so you understand your relative confidence level<br>
13
Rothman’s Example Create Approximate Estimates for Management Team has 3 Feature sets with good detail on the stories
Team had 2 or more Feature sets with little or no detail about the stories
The challenge: Mgt. wanted their best Estimate in two days!
The team estimated one day for each one-point story and roughly 354 days!
“If we do all this work and nothing horrible happens, we think it will take us roughly 70 weeks and with 50% confidence
We can deliver interim value starting in 2 weeks
Every couple of weeks the estimate will be updated
When would you like to know more?”<br>
Team had 2 or more Feature sets with little or no detail about the stories
The challenge: Mgt. wanted their best Estimate in two days!
The team estimated one day for each one-point story and roughly 354 days!
“If we do all this work and nothing horrible happens, we think it will take us roughly 70 weeks and with 50% confidence
We can deliver interim value starting in 2 weeks
Every couple of weeks the estimate will be updated
When would you like to know more?”<br>
14
Rothman: “Instead of using relative estimates, consider using Story counts<br>
15
Estimating Support Work – interruptions! Stop what you are doing!
Estimate the support work to be done
For the next 3 iterations, measure the amount of support work done by the team… track support work “cycle time”
After 3 iterations… is the Cycle Time clustered around some average or mean?
If so, leave time in the iteration based on the team’s history of dealing with the number and type of support items
Compensate for different types of support work… easy versus difficult<br>
Estimate the support work to be done
For the next 3 iterations, measure the amount of support work done by the team… track support work “cycle time”
After 3 iterations… is the Cycle Time clustered around some average or mean?
If so, leave time in the iteration based on the team’s history of dealing with the number and type of support items
Compensate for different types of support work… easy versus difficult<br>
16
… more on “support work” Rothman comments on whether or not to fix the problem now or later…
… accumulate several fixes and schedule time to fix them all
Fixing time … redesign of the code and testing
Note: Putting off the “fixing” results in TECHNICAL DEBT and keeps WIP high
Multitasking is a barrier to any kind of estimating!<br>
… accumulate several fixes and schedule time to fix them all
Fixing time … redesign of the code and testing
Note: Putting off the “fixing” results in TECHNICAL DEBT and keeps WIP high
Multitasking is a barrier to any kind of estimating!<br>
17
Use previous data to inform your next estimate Rothman’s recommendation… for the team to create and refine stories so that each story takes only a team-day or less…
If the actual work is “done” in a team-day, the estimated number of story points is the same as the number of Sprint days
Velocity (a SCRUM definition) the average number of story points “done” at the end of a Sprint
Clearly, using a team’s velocity depends on the rate of completion!<br>
If the actual work is “done” in a team-day, the estimated number of story points is the same as the number of Sprint days
Velocity (a SCRUM definition) the average number of story points “done” at the end of a Sprint
Clearly, using a team’s velocity depends on the rate of completion!<br>
18
Use previous data to inform your next estimate Use the team’s current velocity to feed that information forward to your next estimate
Teams new to agile methods need 6 to 7 iterations to discover their velocity
If the team’s velocity is not stable from one iteration to the next, count feature story point separately from defect points, separately from changes
Once the team’s velocity is stable (+/ –)10%, the team can check current estimates against this “metric”
Note: avoid estimating too far into the future…<br>
Teams new to agile methods need 6 to 7 iterations to discover their velocity
If the team’s velocity is not stable from one iteration to the next, count feature story point separately from defect points, separately from changes
Once the team’s velocity is stable (+/ –)10%, the team can check current estimates against this “metric”
Note: avoid estimating too far into the future…<br>
19
Consider the value of #NoEstimates “Too often the Product Owner wants to change the stories to provide more value”
The result being that prior estimates are no longer valid!
“Work without estimates, instead worked by value”
Rothman
If the team is working without estimating, but instead by “value” and the team is providing a steady throughput of value… estimate may not be needed.
However, the team doesn’t know when it will be “done” until it is “done”
… the team releases value at the end of each iteration<br>
The result being that prior estimates are no longer valid!
“Work without estimates, instead worked by value”
Rothman
If the team is working without estimating, but instead by “value” and the team is providing a steady throughput of value… estimate may not be needed.
However, the team doesn’t know when it will be “done” until it is “done”
… the team releases value at the end of each iteration<br>
20
Estimation Traps The team thinks experts who “sign-up” for their own stories will help the team’s throughput.
Managers misunderstand the idea of velocity and use it as a target for the team to achieve.
Sometimes the team thinks it can do more – with no data behind that thinking
Your organization wants your team to estimate the entire project before it starts delivering value<br>
Managers misunderstand the idea of velocity and use it as a target for the team to achieve.
Sometimes the team thinks it can do more – with no data behind that thinking
Your organization wants your team to estimate the entire project before it starts delivering value<br>
21
Trap: Experts take their own stories “When experts work alone, the team creates WIP, often substantial WIP
Instead of the team collaborating, each person tries to make progress alone…
However, the people on the team need each other to make progress
For example: developers and testers need to collaborate to finish a feature
When experts take their own story, the team creates queues of work”<br>
Instead of the team collaborating, each person tries to make progress alone…
However, the people on the team need each other to make progress
For example: developers and testers need to collaborate to finish a feature
When experts take their own story, the team creates queues of work”<br>
22
Trap: Experts take their own stories What to do…
Have team members estimate as a team
Ask the team to work as a team… developing a practice of working together
Make delays visible… to be dealt with in the team’s retrospective
Note… when experts do their own thing, they optimize for themselves
… when team members take stories together, they optimize for working as a team to deliver results!<br>
Have team members estimate as a team
Ask the team to work as a team… developing a practice of working together
Make delays visible… to be dealt with in the team’s retrospective
Note… when experts do their own thing, they optimize for themselves
… when team members take stories together, they optimize for working as a team to deliver results!<br>
23
Trap: Double Your Velocity … often a manager or project manager that wants the team to go “faster”
Initially, velocity is the team’s estimate of how many story points they can take on in each Sprint… again, the estimate is a guess
At the end of each Sprint… the team’s retrospective assessments may result in adjusting the Sprint velocity
“The team isn’t going slowly on purpose…” – unless there is no collaboration and high levels of dysfunction!
… – unless developers don’t design, but code and fix … do not refactor, do not comprehensively test … do no refactoring producing spaghetti coded design<br>
Initially, velocity is the team’s estimate of how many story points they can take on in each Sprint… again, the estimate is a guess
At the end of each Sprint… the team’s retrospective assessments may result in adjusting the Sprint velocity
“The team isn’t going slowly on purpose…” – unless there is no collaboration and high levels of dysfunction!
… – unless developers don’t design, but code and fix … do not refactor, do not comprehensively test … do no refactoring producing spaghetti coded design<br>
24
Trap: We can do more Wanting the team to do more… stretch goals are set!
“Stretch goals don’t belong in estimates… the team’s velocity is based on a sustainable pace.”
“… velocity is not acceleration”
Velocity may improve as the team assesses the work in end of Sprint “retrospectives … learning and improving<br>
“Stretch goals don’t belong in estimates… the team’s velocity is based on a sustainable pace.”
“… velocity is not acceleration”
Velocity may improve as the team assesses the work in end of Sprint “retrospectives … learning and improving<br>
25
Trap: We need detailed Estimates for “all” of it “Sometimes the Product Owner thinks the team must estimate the entire feature set even though the feature se is large and the team will deliver the features incrementally.”
… but also the “company”
Project Management Office (PMO)
or the “client Product Owner” needs to know “how long” and “how much”
Again, remember … good Estimates are not more that educated, well thought out guesses!<br>
… but also the “company”
Project Management Office (PMO)
or the “client Product Owner” needs to know “how long” and “how much”
Again, remember … good Estimates are not more that educated, well thought out guesses!<br>
26
Rothman’s options to be considered What does the Product Owner need?
Prioritize the needs
“It’s possible the later stories will take less time…”
Doesn’t seem like this would be a meaningful commitment
Don’t increase the team’s commitment in each sprint
Again, the Product Owner needs to prioritize the needs
Provide end of sprint feedback …
Ensures the Product Owner that added value is accumulating and feature sets are getting “done”<br>
Prioritize the needs
“It’s possible the later stories will take less time…”
Doesn’t seem like this would be a meaningful commitment
Don’t increase the team’s commitment in each sprint
Again, the Product Owner needs to prioritize the needs
Provide end of sprint feedback …
Ensures the Product Owner that added value is accumulating and feature sets are getting “done”<br>