10 top tips to Estimating in Agile Projects
I was recently asked a question about Estimating in Agile Projects by one of our AgilePM students in Sydney, Australia. For me, it was quite interesting to revisit the DSDM guidance on the subject and so I thought I’d share what I found with you, hopefully you’ll find it interesting and useful too.
What is Agile estimation?
In typical terms, an estimation is nothing more than a well educated guess. However when you’re estimating in Agile projects, the estimation tends to have three main characteristics:
- Team collective estimate
- Relative estimate
- Estimate velocity
Estimating in Agile projects is about estimating the amount of work needed for the team to successfully complete the project. These estimates need to feel comfortable for the team (typically about 7 people) to achieve, as well as reliable and trustworthy for the business.
Why estimate in Agile projects?
In the majority of projects estimates can be used for many purposes, for example:
- Evaluate a Business Case
- Assess Feasibility
- Plan project schedules and costs
- Communicate with stakeholders
Creating a good estimate leads to increased motivation within the team and the business; the accuracy of the estimate conveys a true representation of the projects and limits uncertainty. Estimating in Agile projects also influences prioritisation so things are developed in the correct order, this reduces the risk of over running which then leads to features of the project being removed to save time.
10 top tips to estimating an Agile project
The DSDM then provided top tips for estimating, which we think can apply across any Agile Project.
- It is reasonable (and acceptable) to challenge an estimate — i.e. to question the assumptions that form the basis for the estimate, since they may be based on a misunderstanding. It is NOT reasonable (or acceptable to challenge the final figures and ask for a smaller number (for example in order to force more work to be done in the time)!
- Estimating for small pieces of work is more likely to be precise.
- Encourage the practice of providing a range where being precise is risky. This is very typical of early estimates at which point it is better to estimate something as, say, 5-10 days and be accurate (by delivering within that range) than it is to estimate something as, say, 7 days (being artificially precise) and be proven inaccurate when delivery takes 8 days.
- Always ensure the team who will do the work create the estimate — they have a vested interest in creating a valid, realistic estimate and will be more committed to achieving it.
- Encourage the team to compare their estimates to actuals, to help them identify estimating problems. The AgilePM can then use facilitative techniques to help the team resolve these problems.
- The best estimates happen when estimating is done by the whole Solution Development Team. The group discussions start to highlight omissions and misunderstandings and help to create a firm agreed base for the estimate.
- Re-estimation happens throughout the project. Use MoSCoW prioritisation to remain on track.
- Do not allow the desire to protect initial estimates to prevent change from occurring. Learning occurs as the project progresses and freezing the scope just means the project may miss many of the stakeholders’ key requirements.
- Protect the team from external pressure to provide more certainty in their estimates than is possible in early stages of a project. Otherwise the estimates become inflated to cover risk of “being wrong”. (MoSCoW. is how DSDM deals with uncertainty).
- When using estimates to calculate elapsed time to complete, remember to allow for”non productive” time e.g. dealing with emails, attending non-project meetings, etc. A typical starting point is to assume 4/5th of a working day is spent on productive work
In DSDM the precision of estimates and the level of confidence increases as the knowledge of the requirements increases and the uncertainties decrease.
From the author
Thanks for reading these 10 top tips to estimating in Agile projects, I hope you found this short read useful.