Estimating in an agile way

People would love it if we could predict the future. We get this all the time in our work:

• How much is the project going to cost?
• When will it be finished so that we can go live?
• We are really busy so how much of Dave’s time do you need next month?

We only get the actual answers to these questions after the work is done (occasionally years later) but people need estimates, forecasts and indications to help coordinate people and activities. Agile ways of working do not immediately remove these needs but techniques like Scrum can help avoid some of the common pitfalls.

About agile in Cornwall Council

We are starting to adopt more agile ways of working. My role involves helping people develop their skills and apply agile techniques to improve the services we provide to the public. This series of posts is adapted from the articles I write for our internal teams. They cover some common agile terms and what it all really means.

Avoiding the common estimating pitfalls

Here are some examples of how agile ways of working can help:

• Agile approaches encourage stable, long-running teams which can make cost management much easier, especially in the public sector where money is often locked into specific financial periods.
• Two people can take a very different amount of time to perform the same task. The agile emphasis on team working can smooth out these differences and be more predictable.
• The timescales for delivery are often dominated by delays between work rather than the effort to complete the work. Multi-skilled teams working on small batches can massively reduce these delays.

How can you start to take advantage of agile ways of working in estimating? Here are some suggestions to get started.

Engage and educate your stakeholders

It is quite reasonable to ask for estimates but people can get into the habit of asking for far more detail and accuracy than they actually need and usually more than you need to manage your work well. You may also find that people have had a bad experience in the past and mistakenly use estimates to try to control teams, put people under pressure or to gain a negotiating advantage. Your stakeholders won’t change over-night but you can try to have an honest conversation about:

• what information they really need to do their job
• the unavoidable uncertainty involved in the kind of work we do
• the sorts of things they can do to help the work go well.

Over time you may find people start asking for different things. Some people even stop asking for forecasts when they can see and touch what the team has delivered in regular demonstrations.

Use sprints to keep improving your estimating

Working in sprints^[1] does several things which help with estimating.

• Getting work done in small chunks sometimes eliminates the need to estimate. For example, waiting two weeks for the actual answer, or a much better informed answer could be better than an immediate but uninformed guess.
• Sprints create a very fast feedback loop so you can see how accurate your estimates are, look at what you missed while it is fresh in your mind and see if you can adjust in the next sprint. For example, how much time was taken up by unplanned work and what allowance can you make for it next time?

Over a few sprints you will start to see patterns and trends^[2] which you can use to guide decisions. The sorts of things teams can do with this are:

• make and maintain longer range estimates based upon actual delivery progress
• improve risk management by understanding how steady or volatile their work is
• make the case to automate or standardise things to make work more predicable.

Move from individual to team-based estimates

Individual estimates are really hard to get right because they are sensitive to so many factors:

• do we know in advance what skills are need to complete the work and who in the team has these?
• if the individual has the skills how proficient and productive are they?
• if they are absent or busy on other things when the work is needed, what happens?

Looking at all of this at a team level can help by smoothing out the individual variations and allow the team to move work around as events play out. You end up with less precise but more robust estimates and, for many people, this is more useful that precise but volatile estimates. You can introduce team-based estimating by:

• adding up the total amount of work that the whole team can do together in the next sprint
• considering the total amount of work that could be needed to complete each backlog^[3] item
• reviewing these estimates each sprint and then adjusting.

Some teams find it helpful to change the units they use for estimating (e.g. story points^[4] or t-shirt sizing) so they can cover things like risk and complexity along with quantity in a single measure of how hard a bit of work is.

Footnotes