Estimation

Estimate is nothing but an approximate time to complete some task. For example: Before you commission a painter to decorate your home or a mechanic to fix your car, you get an estimate from them, right? Approximate time taken to paint the exterior of house? May b 2 days or 5 days. Estimates can be used for several purposes: to evaluate a Business Case, to assess feasibility, to plan project costs and schedules and to communicate with stakeholders. An estimate is a forecast of how much it will take to deliver a specified requirement in terms of cost, effort, skills and duration or, conversely, how much functionality can be delivered for a given cost, effort, skills or duration.

Agile Estimation

Traditionally, project managers tend to focus on creating detailed estimates that can withstand scrutiny from the finance team. Of course, this is based on ‘known known’ with some contingency for the ‘known unknowns’. Estimates are carried out at all stages of a project, initially to help planning. Throughout the project, these initial estimates should be validated and revised to give increasing precision based on emerging detail, the validation of assumptions and actual measures of project performance. A tern expects early estimates to give a broad picture, sufficient only to support the decision on whether or not to proceed. They are not expected to lay down a precise shape for the project and estimates are expected to change as more information becomes available. Estimating can be a really healthy activity, so long as the whole team collaborates on it together. It helps foster a buy-in from the whole team and ensure that everyone gets a common understanding of the scope and value to be delivered.

Measures of Size

One of the main issues with traditional estimation techniques is the fact that team members really don’t believe their project timeline until they’ve completed detailed analysis of the features. They don’t feel comfortable until they’ve completed functional specifications and correlating technical designs. Then, when they complete this work, they’re often surprised and have to notify stakeholders that they can’t make the timeline without a decrease in scope or other project adjustment. In agile we use size to measure.

To avoid setting an expectation that we’re talking about cost and time, we estimate the complexity of a story, some of us like to refer to this as ‘sizing’ rather than estimating.

Two different techniques used as measure of size are:

• Story Points

• Ideal Time

Story Points

Story points are a different way to look at estimating features. They aren’t a measure of the time needed to complete a feature but a measurement of a feature’s size relative to other features.  This approach is powerful because you may not have enough information to estimate the time to create a feature, but you can immediately begin to compare the sizes of features to each other to determine a relative size. Let’s assume you’re making passenger cars instead of software. The cars are as Mini Cooper, Honda City, Honda Civic, and Town Car. You know a Mini Cooper is probably the smallest car of all. You know that a Honda City is a medium-size car, and you know that a Town Car is probably the largest of them all.

A popular scale for estimating feature size is the Fibonacci scale, which sums the previous two numbers to derive the next number in the sequence. The sequence looks like this: 1, 2, 3, 5, 8. The main benefit of the Fibonacci scale is that enough separation exists between the numbers to prevent the team from squabbling over slight differences. By selecting a 2, you still have room to list an item as smaller; if you identify a 5, you have room to estimate another feature as larger, and you also have the ability to compare a list item to two other list items. Now comparing the relative size of various automobiles and after collaborative tem decision we come to conclusion that: 

• Mini Cooper – 1

• Town Car – 8

• Honda City – 3

• Honda Civic is 5

In parallel to Fibonacci series we could also size stories using t-shirt sizes (S, M, L, and XL).

• Mini Cooper – S

• Town Car – XL

• Honda City – M

• Honda Civic is L

How to Estimate?

At the end of each iteration, the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity.

Example - An agile team has started work on an iteration, planning to complete stories A and B, estimated at 2 points each, and story C, estimated at 3 points. At the end of the iteration, stories A and B are 100% complete but C is only 80% complete. Agile teams generally acknowledge only two levels of completion, 0% done or 100% done. Therefore, C is not counted toward velocity, and velocity as of that iteration is 4 points. If user stories remaining represent a total of 40 points; the team's forecast of the remaining effort for the project is then 10 iterations

Ideal Days

As per definition Ideal Days is the number of days of effort that it would take the team to get a story done if the team worked with no interruptions. Ideal Day estimates are not really dimensionless. One Ideal Day represents the amount of work an average developer could complete in one eight hour day completely free of interruptions such as drop-ins, phone calls, meetings, etc. Let’s assume, for 7 member team, and 2 week sprint they ideal says is 46days. So if we say 80% of time is ideal time then total ideal days should = .8*10*7 = 56days. Hence team should pick more stories to be delivered this sprint. Ideal time is not equal to elapsed time

While calculating Ideal time we must consider:

• Supporting the current release

• Sick time

• Meetings

• Demonstrations

• Personnel issues

• Phone calls

• Special projects

• Training

• Email

• Reviews and walk-throughs

• Interviewing candidates

• Task switching

The Ideal Day metric is still an abstraction of time estimates. We don’t plan off the Ideal Day on a timeline, but instead use team velocity matched with Ideal Days to equate to time-lining User Stories from a high level. In short, an ideal week for a single developer looks a lot like half of a "man-week". Looked at differently, a developer has a capacity (or velocity) of 0.5 ideal weeks per calendar week, or for a two-week iteration, about one week of ideal effort.