Reliable Estimates Using Agile

Estimation is actually quite easy as long as you keep your expectations under control and follow the rules.

Reliability and Accuracy

Reliable Estimates that are Useful and Believable

Everyone wants reliable estimates that are useful and believable. An estimate is reliable when the team can assure they can deliver the User Story on time (“Acts of god” don’t count). Always delivering on time builds trust and reduces risk for the customer.

A useful and believable estimate is an estimate that isn’t obviously overly cautious and allows the product owner to plan their releases.

Someone could ask the team “How long will it take you to write this blog on estimation” and the team could say “4 years”. Reliable? Yes. Believable. No. Useful? No. What is the product owner going to do with an estimate of 4 years? How are they going to prioritize that estimate?

Accurate Estimates

An accurate estimate is an estimate that falls close to the actual time it took to get the User Story approved by the Product Owner. It is hard to be accurate in estimation and very hard to be accurate and reliable. There are a lot of factors involved in making an accurate estimate (see Adjusting For Risk Below).

Back to the estimate above... I could say that it will take the team “2 hours and 30 minutes to write this blog”. Am I accurate? It sounds accurate. It is reliable? Am I sure that the team will really meet the deadline of 2 hours and 30 minutes? I have no idea. What if I said 1 day? My guess is that one day is not very accurate.

Agile Doesn’t Require Accurate Estimation

What makes agile estimation so powerful is that you don’t need to be accurate. You just need to be reliable. Estimation is done with story points, and in every iteration everyone can see how many story points are completed. After 3 or 4 iterations, a pattern emerges called velocity. Velocity is the natural accuracy of a team.

A team that is able to complete 10 story points in 5 days has a velocity of 2 stories points per day (Velocity is usually per iteration). A team could try for 10 story points a week and that should be accurate. To be reliable, a team could try for 8 - 12 story points keeping the product owner aware that 8 is the absolute minimum that will be delivered: a very reliable estimate.

Of course, if velocity is all over the place then it means the team is having trouble estimating. There are ways to mitigate this as I will discuss in the blog on Agile Estimation.

The Dangers of Estimating for Accuracy

An accurate estimate improves your chances on getting a new customer. However, it also increases the chance of losing an existing customer. After all, the Product Owner wants a reliable team with useful and believable estimates. A team always missing their deadlines simply because they are trying to be accurate will cause the Product Owner to loose faith in the team and eventually the company the team works for.

Preparation Before Estimation

Before estimation you need:

A Cross-functional Team - The team does the estimation. The team is doing the work so they need to do the estimation so they can commit to it. The Product Owner, Agile Master, Stake Holders and Sales People do not do the estimation. I emphasise cross-functional as you need “experts” to estimate specific functions (pouring cement, building a wall, database back end, etc.).
Availability - For each team member, you need their availability for the project. They may split their time between projects, have paid time off to take, need to rest (people really can’t work 8 hours straight), or maybe the company sets aside 10% of their time for research.
Definition of Done - You need a detailed definition of done: what it means when you are delivering a User Story to the product owner.
User Stories - This is what you are estimating.

Estimating a User Story

Right, so you are on a team (. You know your availability and all your team members availability. You’ve studied and actively applied the definition of done for the project. You have user stories clearly defined by the Product Owner. Let’s being.

Writing User Stories that can be Estimated

It is very important that a story can be estimated. What makes a good story which can be estimated?

Short Period of Time - A story should be deliverable in about one day and at most a few days (We are really saying they should be no larger than X story points where a story point represents about one half of a day. This is possible to determine once velocity is known.). If it looks like the story is going to take longer than two days, it should be broken down into smaller stories. The larger the story, the less useful and believable the estimate will be.
Broken Into Tasks - A story should be broken into small tasks. These shouldn’t be estimated individually but used during the estimation process.
No Unknowns - A story that has any unknowns needs to be researched before it can be estimated. Any stories that need research should be given points to research and attempted first.
Other key factors that make a good story - There are other key factors that make a “good story” that also helps in estimation. For example, a story should be independent of other stories. More could be provided but deserves another blog.

The Agile Estimation Process

Finally, the agile estimation process is applied to actually estimate the stories. Instead of writing about this process in this blog, I will provide another blog that focuses on just the agile estimation process.

Choosing the Hard Stuff First

This does not have an effect on individual stories but does have an effect on the success of the project as a whole. It is of utmost importance that the riskiest stories are completed first. If a specific unknown technology actually doesn’t work, it might mean the entire project is not possible. It is better to find that out before all the money is spent.

Adjusting For Risk

This is an incomplete list of things you can do to improve on your estimates.

Experts on the team - Optimally, you would like to have a seasoned team whose members have been working together for three to four iterations doing estimation. They know each other and their limitations by this time. At least one team member, and preferably two, are experts in each specialized field (pouring cement, driving a car, database design, etc.)
Creation of a new team - It takes a while to determine the velocity of a team. Adjust what you commit to initially or just commit what you feel you can do as a team and let the process adjust it for you.
Addition/Removal of a team member - This will affect the velocity of a team. Take this into account when estimating.
Contains Unfamiliar Technologies - This adds risk as the team might not know all the dangers lurking around the corner. You can get outside advice when estimating, add experts to the team or assign points to research the story before estimating it. Of course, you could always stick to the technology everyone knows but this will lead to stagnation.
Stick to the Agile Rules - Assure you are following agile at all times. Make sure everyone knows their responsibility and that they have the authority to execute that responsibility. If anyone not involved is able to get in the way, then estimates are less reliable. If there are people who can “stop the train” then be sure to adjust for that.
Assure all User Stories are Estimate-able - If there is any User Story that can not be easily estimated, then break it down into smaller stories. Remember, the smaller the thing your are estimating, the more reliable the estimate will be.
Paired programming - Reduces risk when one of the pair is unable to work for a short or long period of time. The other pair is able to continue without delay to the project.
Stories with Long Wait Times - In some cases, a User Story may involve delivery on the part of a third party. For example, you may need a custom part developed for a race car. Any user stories with long wait times from 3rd parties should be started as soon as possible.
Don’t stick your head in the sand - Agile estimation does say to only estimate and implement what is required today. That doesn’t mean you can stick your head in the sand. If you know something is going to be a problem, you should research it or mitigate the risk even if business value won’t be added until later.

Conclusion

Estimation is not only possible but it can actually be easy. You simply have to follow the agile estimation process and keep in mind the key points brought up in this blog. Remember, you are trying for reliability that is useful and believable. You don’t need accuracy as that emerges naturally from the agile process itself.

Next week I will blog about the agile estimation process.