Agile is becoming the most popular delivery methodology in the IT industry, with the following benefits:
- The Scrum team will deliver working modules on a regular interval – Sprint
- Frequent deliveries give opportunity to Client for giving feedback and suggestions and keep control on project progress. This will also give clarity on the progress on overall project delivery at any point of time
- The Client will get flexibility to priorities the User Stories for each Sprint
- Agile forces to test frequently, resulting in improved quality for end product
- Collaborative approach results into better alignment of end product with business objective
- Faster time to market
The estimation in Agile – Scrum is different, easy to understand and quick to implement. This white paper will throw some light on Agile Estimation Techniques covering what, why and how?
The main difference compare to Waterfall estimation is:
Instead of a manager/ solution architect estimating efforts on behalf of team members, Scrum team estimates their own efforts.
Different ways of estimation in Agile:
- Numeric sizing (1 through 10),
- T-shirt sizes (XS, S, M, L, XL, XXL, XXXL),
- Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.),
- Dog breeds
All are RELATIVE type of estimation techniques.
Why Relative Estimation?
- Scrum is open for any estimation techniques. This also includes absolute numbers like man-hours or days as well.
- The 3 main reasons for using relative sizes.
- Generally human beings are bad at absolute estimates but good at relative comparison. Let’s check out the following example. Please see the following 2 shapes and answer: How big is the first shape and also the other one (question asked for absolute estimate)? If I ask you now, how much bigger the second shape compared to the first one? (question asked for relative estimate). Usually, we are fast and better to answer the second question than first one.
- The relative estimates are faster and cheaper.
- In relative estimation team won’t argue over relative sizes compared to time bound/ absolute estimates.
- No need to re-estimate relative sizes for any change. If something changes, the estimates remain the same and only velocity changes.
Agile community research in the psychology of planning shows that people are better at relative than absolute estimation.
- Size Estimation: This will give a high-level estimate for the work item, measured in a unit called as points (story points).
- Velocity: Points delivered by the team / Iteration
- This velocity is measured and not estimated, so you don’t need to spend a buck on getting it.
- Effort Estimation: Translating the measured story points to detailed efforts in hrs. To prepare schedule with required resources. NOT RECOMMENDED
Yes, it is possible to forecast release date with agile estimates if you have a stable team with a known velocity
What is a Story Point?
- Story Points arose from the observation that it’s very difficult to estimate tasks in absolute units like hours when the task is not yet well-defined, and estimation itself takes time, time that might be better used to produce results. Estimating tasks in hours or days also fosters a false sense of precision.
- Points are unit-less.
- The most important thing to remember is that story points do NOT equal units of time. Initially you will naturally find yourself trying to convert story points to days, or estimating in days or hours, and then trying to convert that to story points.
- The number of story points associated with a story represents the overall size of the story.
- Most Scrum teams use some kind of altered Fibonacci scale to do relative estimates
Story Points are an abstract metric that measures the functionality of a User Story without any relation to time and effort with a scale that is not mathematically predictable.
- Most Scrum teams use some kind of altered Fibonacci scale to do relative estimates. So standard Fibonacci goes 1-1-2-3-5-8-13-21-34-55-89 and so on. Most teams use a sequence similar to 1-2-3-5-8-13-21-40-100.
- The reasons are simple:
- If you ask a developer how much bigger something is compared to something else, she most often will tell you “twice as big”. In Fibonacci there is no “twice as much” and thus people have to make a decision. Some will go for the higher number; some will go for the lower value. The important thing is the resulting discussion: Suddenly, people need to state a reason for why they chose their number. Comparing the reasons leads to a discussion that clarifies many different aspects for the developers. This discussion constitutes the true value of the estimation process.
- Many teams do not cling to true Fibonacci because in the upper regions “34”, “55”, and “89” imply a certainty that simply doesn’t exist. Stating “40” instead of 34 or “100” instead of 55 transports a coarse-grained granularity that reflects the uncertainty in these regions. Simply speaking, the team tells their Product Owner by showing “40” that “this item is too big and has to be refined” while “100” basically means “this will never fit into a Sprint, more refinement is needed”.
- The bigger the numbers, the greater the gap between them. This helps to illustrate that estimates become less reliable with growing size.
So Fibonacci numbers are excellent to facilitate discussions in the context of estimation
Story Point Estimation:
Story-point estimate can be done on the basis of the following parameter:
- Unpleasant technical surprises
- External dependencies
- Experience of Team
- Implementing developer skill level
- Available domain knowledge
- Extra small: 1, 2
- Small: 3
- Medium: 5
- Large: 8
- Extra Large : 13
- Too large for 1 Sprint : 21 points
- During the estimation meeting, each team member will be given one deck of the cards. All decks have identical sets of cards in them. (0, ½, 1, 3, 5, 8, 13, 20, 40, 100, ∞ and special cards like ?, coffee (optional))
- The meeting proceeds as follows:
- A Moderator, (usually Scrum Master) who will not play, drives the meeting.
- The Product Owner / BA will read out the story. The team will be given an opportunity to ask questions to clarify their assumptions and identify dependencies if any.
- After the discussion gets over, each team member lays a card face down representing their estimate.
- Scrum Master asks the team for “Show”, everyone calls their cards by turning them over at the same time. People with high estimates and low estimates are given a chance to explain their considerations / justification. This step will be repeated until a consensus is reached, estimate is noted down and we move to next User Story
- Planning Poker is a good way to come to a consensus without spending too much time on any one topic. It allows or forces, team to voice their opinions, thoughts and concerns.”
- Planning Poker is the best way we’ve found for agile teams to estimate. Its primary downside has been that all participants had to be sitting in the same room with a physical deck of cards in their hands.
- Now, this free online tool let’s distributed teams take advantage of Planning Poker, too. http://www.planningpoker.com
- Quicker than other methods
- No influence on estimation
- Everybody has to participate and share their understanding and an opinion leads to healthy technical discussion
- Encourages communication and collaboration with in the team.