The aim of this publication is to consider usability of estimation in software development context. We will cover here a matter of estimation rather than exact estimation techniques. The consideration has in mind particularly agile environment. I wrote this post basing on my experience and observations. I have worked in various teams with different approaches to estimation. In some teams estimation techniques were changed along with time.
Introduction
Wiki definition of estimation:
Software development effort estimation is the process of predicting the most realistic amount of effort (expressed in terms of person-hours or money) required to develop or maintain software based on incomplete, uncertain and noisy input. Effort estimates may be used as input to project plans, iteration plans, budgets, investment analyses, pricing processes and bidding rounds [1].
There are other units of estimation in addition to those mentioned in this definition. These could be for instance ideal days or story points. Regardless of the unit, these are all numbers. On a planning session of Scrum Team there is often effort put on providing numbers matching team velocity. Is it really necessary to do so? Do we really need such an estimation? In most cases the goal is providing right backlog content for a given sprint. Right sprint backlog is important, estimating is only a process which help us composing a new sprint backlog.
Feasibility of estimation
Is it possible to predict how much time is required in order to provide an implementation fulfilling all the acceptance criteria? In Scrum, the general assumption is working on complex tasks. Complex things suffer from unpredictability. Ultimately, technical considerations and tasks decomposition are rarely completely done during iteration’s planning. That is very often not possible because of unprecise requirements, technical nature and human factors. It is also not possible providing more precise outcome than the foundation that we rely on. We are loosing precision on each composition level. If a primal task’s estimation is uncertain then the feature’s estimation composing this kind of tasks will be even more uncertain. Going further, epic built upon such features will have more noise in estimation. Finally, estimation of a new sprint backlog will be full of uncertainty. However, it is possible to achieve estimation on a certain precision level. It will vary from project to project and from team to team. Estimation will be especially precise for predictable tasks and for mature teams. There are techniques helping providing efficient estimations. Some of them can be found on [2], [3]. Agile Estimating and Planning [4] is a very popular book dealing with agile estimation. Many techniques are focused on providing numbers expressed in unit of time. Considering the arguments above addressing uncertainty on different levels, we may end up with a conclusion that time is not a unit of success. Estimation in time very often brings disappointment.
Estimation context
Estimation method working today may not be valid forever in changing environment. For example when a team composition is changing then estimations may become less precise. There is no one ultimate technique to compose sprint backlog. Estimation is really hard. This is a hard work for a team to find a way to the efficient estimation approach. In agile, emphasis is put on continuous inspection and adaptation. Estimating method in agile teams is one of those issues which requires care of these activities. Estimation unit should be adequate to characteristic of tasks. For teams working mainly on timeboxed spikes it is relatively easy providing estimation even in time units. Estimation based on gut feeling does not require sophisticated analysis while the idea is to include certain tasks set into sprint which we think we will implement. Estimation based on gut feeling is a sign of a mature team.
Estimation vs. commitment
Commitment is what we promise to deliver on a certain time whereas estimation is what we predict to implement until the time. What happens when we cannot deliver implementation on time?
Usually there are undertaken actions as follows:
- Scope is reduced to implementation which can be provided on time
- Release is postponed
- Code becomes dirty and product implemented this way is released
- There is no time for activities other than coding e.g. testing, refactoring, clean code
The picture behind numbers
There are beliefs that estimation is not so agile. Planning is even less agile. Why? One of the principles of Manifesto for Agile Software Development [5] is responding to change over following a plan. The purpose of planning in Scrum is building backlog for a new sprint. Tasks are usually taken from product backlog. We estimate tasks in order to predict which tasks we will be able to implement during a sprint. We estimate in different units. Hours, days, story points – these are all numbers. Beside pure estimation relying on numbers calculation there are other factors building our confidence of a new iteration. One of them is gut feeling which requires experience and gathering results from previous iterations. Team should have a common picture of new sprint with full understanding what is the goal and what all the tasks are about.
Summary
The final recommendation is to not overcomplicate plannings and estimations. Keep it as simple as possible. Choose a solid approach to organize a sprint backlog suitable for a certain team. Estimation can be seen as an optional tool to provide a feasible backlog. There are mature teams estimating in story points or only basing on gut feeling and they do it well. Achieving such a level of precision and consistency takes time.
References
[1] https://en.wikipedia.org/wiki/Software_development_effort_estimation
[2] http://info.thoughtworks.com/rs/thoughtworks2/images/twebook-perspectives-estimation_1.pdf
[3] https://dzone.com/articles/agile-estimation-practice
[4] https://www.mountaingoatsoftware.com/books/agile-estimating-and-planning
[5] http://agilemanifesto.org/