Understanding Agile Estimating
Published on Mar 21, 2016
Agile Estimation Techniques
MORE DECKS TO EXPLORE
PRESENTATION OUTLINE
Understanding agile estimating
Agile Estimation Techniques
DILBERT:
I need an estimate for my project but I don't have a scope or a design for it yet.
Okay, my estimate is $3,583,729.
You don't know anything about my project. That makes two of us.
I need an estimate for my project but I don't have a scope or a design for it yet.
Okay, my estimate is $3,583,729.
You don't know anything about my project. That makes two of us.
what is an estimate?
- According to dictionary.com:[noun] an approximate judgment or calculation, as of the value, amount, time, size, or weight of something
- In software development world, estimate is just a guess
the cone of uncertainty
the cone of uncertainty
the cone of uncertainty
- Steve McConnell reminds us that initial estimates can vary by as much as 400% at the inception phase of our project
- In agile, we recognize that we can't trust our initial estimates
- Two things that help us estimate the agile way: 1. Estimate things relatively 2. A point based system to track progress
...is A story point?
What the heck...
Point-based system
- It is one number that delivers everything necessary to make the story work
- There are no separate estimates for analysis, design, development, testing, documentation
- Influenced by how hard it is and how much of it there already is
- Our estimates are unitless
relative sizing
- What makes Agile Estimation work is sizing stories relative to one another
- When we size things relatively we are measuring bigness NOT time
- We consider: Complexity - how difficult it seems? Effort - how much of it there is? Risk - current knowledge (uncertainty)
More and more industry leaders are moving away from hour estimates, and are now using the story point approach. This makes sense because in a sprint, the main questions to be answered are:
How much work can we realistically commit to completing this sprint?
How long will this part of the backlog take to deliver?
The story point approach based on original estimates can deliver the answers to these questions without the anxiety around 'accuracy' that teams feel when asked to estimate in hours.
How much work can we realistically commit to completing this sprint?
How long will this part of the backlog take to deliver?
The story point approach based on original estimates can deliver the answers to these questions without the anxiety around 'accuracy' that teams feel when asked to estimate in hours.
Estimating dog sizes
Example: Without any specific knowledge about each breed, it is very easy to align the dogs from smallest to largest. The Yorkie is about twice the size the Tea-cup Yorkies, the Spitz is about twice the size of the Yorkie, and the Bullmastiff is about twice the size of the Spitz.
SO, HOW DO WE GET STARTED?
Let's break it down
- Sit down as a team to review stories with Product Owner
- Ask lots of questions to make sure you understand the Acceptance Criteria
- Develop a baseline for the team of small(1 point) medium(3-5 points) large stories (8-13 points)
- Compare the remainder of the backlog to size it relatively
did someone mention planning poker?
Photo by junyaogura
How to play planning poker?
- Planning poker is one of the tools used for agile estimating
- Each team member is given a deck of cards
- Each estimator selects a card with their estimate (cards are turned over at the same time)
- Team discusses estimates
- Team estimates again until the concensus is reached
Planning poker by mike cohn
story points !=time
estimate the size - derive duration
what about ideal days?
Photo by archer10 (Dennis) (69M Views)
estimating in ideal days
- How long something would take if: 1. It is all you worked on 2. You had no interruptions 3. Everything you need is available
- The ideal time of a football game is 60 minutes (4 quarters X 15 min)
- The elapsed time (duration) is much longer (3 + hours)
Planned activities are affected when people spend time to read and answer email, make phone calls,
attend meetings, address personal issues, attend training, support releases, management reviews,
take sick time, enjoy vacations, perform task switching, assist in fixing software bugs, attend
buddy/peer reviews, and participate in other activities that interfere with meeting commitments.
attend meetings, address personal issues, attend training, support releases, management reviews,
take sick time, enjoy vacations, perform task switching, assist in fixing software bugs, attend
buddy/peer reviews, and participate in other activities that interfere with meeting commitments.
comparing the approaches
- Story points help drive cross functional behavior
- Story point estimates do not decay
- Story points are a pure measure of size
- My ideal days CANNOT be added to your ideal days
- Ideal days are easier to explain
- Ideal days easier to estimate with new teams
The key is, the estimation unit doesn't matter – as long as it becomes reasonably predictable from sprint to sprint. For example, teams can use 'ideal hour' estimates, but it's neither necessary or expected that those hours will have any relationship to elapsed time. If a team has a 'man-hour' capacity of 120h in each sprint but a velocity of 60h, that makes no difference because you can still use the 60h velocity to estimate the number of sprints that portions of the backlog will take to complete — and therefore, the elapsed time.
Many people then start wondering where 'the other 60 hours' went, thereby implying that there is something wrong with team productivity. But that's usually got nothing to do with it: a team's estimates merely represent their view of how hard items will be, taking into consideration the team's natural behavior (such as over- and under-estimation), as well as organizational overhead, etc. The velocity is all that matters from a planning perspective.
Many people then start wondering where 'the other 60 hours' went, thereby implying that there is something wrong with team productivity. But that's usually got nothing to do with it: a team's estimates merely represent their view of how hard items will be, taking into consideration the team's natural behavior (such as over- and under-estimation), as well as organizational overhead, etc. The velocity is all that matters from a planning perspective.
Estimation Exercise
- Estimate how long to get from Minneapolis to Paris?
- 1. Using story points
- 2. Using ideal days
Photo by Stefano Guastalegname
resources and reference materials
- The Agile Samurai by Jonathan Rasmusson
- Agile Estimating and Planning by Mike Cohn
- Estimating Dog Sizes is Easy, Estimating Software is Not by Jeffrey York
