Whether your using Scrum or some other Agile process, at some point you will be asked to Estimate your work. So what is that... as if you didn't already know:
The ability to accurately estimate the time and/or cost taken for a project to come in to its successful conclusion.
- Wikipedia (http://en.wikipedia.org/wiki/Estimation_in_software_engineering)
The truth is; unless you are building templated software like toys on an assembly line; good software estimation is generally some combination of experienced guesswork, historical evidence, dumb luck, and black magic... If you are using processes that require higher fidelity artefact's like CMMI, SW-CMM, etc... then you may be familiar with estimation practices like COCOMO, Delphi or others. If you are working on very large projects, or you need to do long-range estimation, these techniques can make a lot of sense.
In Scrum, you have roughly one working day for the business to articulate its needs and priorities for the next iteration. During this same time the Team has to figure out what they will commit to delivering, how they might do it, who in the team will do it, and how long it might take. With so little time, traditional techniques just aren't practical so the estimation priorities need to be shaped accordingly. A key practice in any project is proper management and communication of expectations, risks, etc... So with that in mind, here are the tenets of our estimation process:
- The artefact should be quick and easy to produce... Keep it simple and reuse your tracking system if possible, letting the assigned task list represent your teams estimate (Ex. TFS, Microsoft Scrum, VersionOne, etc...). It could be as simple as a spreadsheet or even an email to all concerned
- Communicate where the team has a lack of confidence in their estimates and why. Managers can use this to get a sense of how much contingency;if any; they need to add to an estimate to ensure customers are not too disappointed if things go the wrong way
- Communicate what risks, resource shortfalls, or impediments the team is concerned about. This would include things that could place the teams ability to deliver commitments in jeopardy. Generally, these are items that need to be addressed by Product Owners or the Scrum Master
- Communicate any assumptions the team is relying on as the basis of their estimates. This would include things that; if not true; could dramatically change the estimates
This may sound like a lot but this can be done very easily... Here's a sample of a spreadsheet that demonstrates each area:
As you can see, this would take very little effort, allowing the team to spend more time talking about more important details. On the other hand, this clearly communicates the points that shape expectations.
Even if you get the estimates correct, there is still one element that can cause you to estimate incorrectly and technically speaking this should be done before you estimate. What is it?.. Defining your teams Capacity. Essentially, we need to make sure we don't over-commit the team or any one member of the team. This process is pretty straightforward and does not require much more then a white-board discussion. Here are some things that should guide this calculation:
- Will any member of the team be taking a vacation or any other planned time away from the team?
- Are there any company holidays?
- What is the team's productivity rate? This is the number of hours per day each team member is expected to be making progress towards the completion of committed tasks. This tries to achnowledge time spent on the phone, answering emails, attending meetings, training, lunch, etc... No estimate should extend beyond this number
Hopefully these tips will help make your estimates a little more successful.
Tags: processes