Johanna Rothman Agile Estimation: The Good, The Bad, and The Ugly - PowerPoint Presentation

Slide1

Johanna RothmanAgile Estimation: The Good, The Bad, and The UglyChapter 10

Copyright

© 2017

Slide2

“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”

Slide3

Cycle timeTeams 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”

Slide4

Understand VelocityProduct Backlog contains Features and stories for each

featureStories are estimated in “story points” … each story point representing the team’s assessment of the relative difficulty in designing and implementing a user needDesign and development work is carried out in “Sprints” Each “Sprint” (timebox) is a specific number of weeksThe 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

Slide5

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 storyRelative 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” videoAdvice:“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

Slide6

Assessing Story size Large stories have many unknowns… complex

Use a “spike” to determine how you can break the story into smaller, more “manageable storiesGuidelines: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 storiesTypically requires collaboration with the Product Owner in “breaking” such epic stories into a set of smaller storiesAgain: the larger the number of per-story story points, the greater the estimate’s uncertainty!

Slide7

Story PointsThe 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 BacklogRecall the 3-C’s associated with the preparation for the work within the SprintCard (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)

Slide8

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 storiesRothman’s adviceTake 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

Slide9

Cycle Time Estimation examples

Slide10

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

Slide11

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 lessThe entire team understands stories across the product“Consider counting stories for your estimates”???Page 155

Slide12

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 doneHow 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 featuresUse whatever relative sizing approach you prefer

Walk through the roadmap, estimating as you goCount larger features… the larger the feature, the more estimation uncertaintyAdd up your relative estimate (points or cycle time)Add up the large features so you understand your relative confidence level

Slide13

Rothman’s ExampleCreate Approximate Estimates for Management

Team has 3 Feature sets with good detail on the storiesTeam had 2 or more Feature sets with little or no detail about the storiesThe 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?”

Slide14

Rothman

: “Instead of using relative estimates, consider using Story counts

Slide15

Estimating Support Work – interruptions!

Stop what you are doing!Estimate the support work to be doneFor 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

Slide16

… 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 testingNote: Putting off the “fixing” results in TECHNICAL DEBT and keeps WIP highMultitasking is a barrier to any kind of estimating!

Slide17

Use previous data to inform your next estimateRothman’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 daysVelocity (a SCRUM definition) the average number of story points “done” at the end of a SprintClearly, using a team’s velocity depends on the rate of completion!

Slide18

Use previous data to inform your next estimateUse the team’s current

velocity to feed that information forward to your next estimateTeams new to agile methods need 6 to 7 iterations to discover their velocityIf the team’s velocity is not stable from one iteration to the next, count feature story point separately from defect points, separately from changesOnce the team’s velocity is stable (+/ –)10%, the team can check current estimates against this “metric”

Note: avoid estimating too far into the future…

Slide19

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”RothmanIf 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

Slide20

Estimation TrapsThe 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 thinkingYour organization wants your team to estimate the entire project before it starts delivering value

Slide21

Trap: Experts take their own stories“When experts work alone, the team creates WIP, often substantial

WIPInstead of the team collaborating, each person tries to make progress alone…However, the people on the team need each other to make progressFor example: developers and testers need to collaborate to finish a featureWhen experts take their own story, the team creates queues of work”

Slide22

Trap: Experts take their own storiesWhat to do…Have team members estimate as a team

Ask the team to work as a team… developing a practice of working togetherMake delays visible… to be dealt with in the team’s retrospectiveNote… 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!

Slide23

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 guessAt 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

Slide24

Trap: We can do moreWanting 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

Slide25

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!

Slide26

Rothman’s options to be consideredWhat 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 sprintAgain, the Product Owner needs to prioritize the needsProvide end of sprint feedback … Ensures the Product Owner that added value is accumulating and feature sets are getting “done”