Estimation & delivery

Image credit: WeGraphics

Estimation & delivery

Some toughs about estimation and delivery.



About Planing:


About Estimation:

Already in 1975, Fred Brooks suggested in Mythical Man Month, Fred Brooks that you should triple any developer estimation.

When you are working with a team the best way to re-adapt given estimation is mathematical formula of estimation. We all know it.

E=D*PI

Project Management Estimation = Software developer’s estimation * PI

For sure there's no silver bullet and this formula should not be applied for all cases. I have since found that π, π^2, and √π are all important magic numbers for project managers.



  • Multiply by π for small, known teams, doing a new job
  • Multiply by π^2 for unknown teams
  • Multiply by √π for known teams who have already started, know their work and have a good track record.


But when there's required to complete the task they have to take the route around the circle. Not only do they have to take a longer trip to reach the other side of the circle, they must also complete the whole circle and that was never in their estimate. You have setting up development environment, merging, build script problems and all that stuff which you never considered. That is the circumference of the task.


The Noestimate movement:

As was described by Scott Mason on madetech: "The #noestimates movement is a subject that has generated a fair amount of controversy in the software development community since its inception, including within the team here at Made.

Within the world of Agile, estimations are part of a number of methodologies, particularly Scrum, with practitioners meeting at the beginning of each sprint to plan out and estimate the work to be done in that period. The meeting gives everyone a chance to raise concerns, ask questions and get a very high level overview of the work that needs doing.

1. They're Estimates, Not Exactimates
Estimates, by definition, are rough guesses, and are ultimately very likely to be off the mark. A piece of work may take longer than expected, and that's fine. Trouble only sets in when developers get attached to estimates and treat them as absolute, immovable deadlines.

2. Chance Favours The Prepared Mind
It's true that we estimate when we know least, but planning and preparation is an important process in any project, in all walks of life. By spending time estimating, with as much knowledge as we have at the time, we give ourselves the best possible plan for the sprint ahead as we discuss and discover the tasks that will likely need the most time spent on them.

3. Trust Issues
The noestimates movement requires a massive amount of trust between you and your client, as you're effectively removing the one thing that gives them a sense of how long the project will take, and how much it will cost them. For most clients, that's a huge risk.

4. Being Bad At Something Doesn't Mean We Quit
Yes, people are typically bad at estimating, but with experience we learn to spot where pain points are likely to arise and adjust future estimates accordingly. We'll still get it wrong from time to time, maybe even drastically so, but estimation remains an essential tool for figuring out a roadmap for the
upcoming sprint."


About delivery: