If it takes a team member more than a quarter of a sprint, your estimate will be wrong.
CONTACT ME TO DISCUSS TRAINING OPTIONS
A lot has been written on Sprint estimates, pointing, or planning poker, but often little will be discussed on estimating larger pieces of work. Often development teams get asked to perform estimates on larger pieces of work that is nowhere near an Epic, let alone a Story. Management still needs these estimates to assign teams, gain funding, quote externally, and plan releases with customers.
No detail, no planning, just “how long will this take”?
Some of these estimates we are asked to make, is almost like asking “How long is a piece of string?”. How should we respond to estimate requests like that? No detail, no planning, just “how long will this take”?
As it turns out, there are various methods we can use to give management that estimate they need and tell them just how long that piece of string is. We do that through being pragmatic. At that stage we simply don’t know enough, but we can still give an estimate. For example, most pieces of string are between 2 to 3 feet long, and your gut feeling in this instance is that this is a little longer – therefore your estimate may be that this piece of string is likely to be between 3 and 4 feet long. That’s it!
To translate this to your development estimates. A piece of work can be estimated to take “about a week, but possibly a little longer”, then estimate between 1 and 1.5 or perhaps 1 to 2 weeks if that feels better for you.
If you can, split the requirement up into manageable pieces first. That will make your estimates a little more understandable and closer to true estimates. Also, estimates that are split into pieces of work are less likely to be re-estimated by management.
If it takes a single team member a quarter of a Sprint or more – your estimate will be wrong.
In software, there is a general understanding that if something takes more than about 20 hours or a quarter of a Sprint (your mileage may differ), then the estimate will be wrong. However, here we are not giving detailed estimates; we are giving management and others “some idea” for them to plan. We know it will be wrong, after all, we don’t know the detail as yet. However, we can give an indication based on experience, your technical knowledge, and gut feeling.
Realistically estimate but don’t over-estimate to save your back, or worse, under-estimate to show how good you are. Simply make it known how certain or uncertain your estimate is and the easiest way to do that is to give upper and lower estimates.
If you really don’t know what you are trying to estimate, relate that “you don’t understand” and get more information.
it’s an estimate, not a quote
One last piece of advice – don’t spend too much time on estimates, it’s an estimate, not a quote.