How Estimates are Made in Scrum

Scrum is one of the most popular frameworks for software projects. This framework entails breaking down the project requirements into small task-sets or sprints, and executing them in an iterative cyclical approach. A key component of this approach is making estimates for the project.

The genesis of making estimates in Scrum is the user creating user stories.

A typical user story contains a statement of what value a user expects from using the software, a listing of the alternative paths to realize the value, and the acceptance criteria. It answers the questions – what and why, of the project. The project team first breaks down big or “epic” stories into its compound elements, fragmenting them into smaller, achievable tasks. Each of these would take about a day or two to complete. The result of this exercise is a Scrum spreadsheet with a list of tasks, known as Sprint Backlog.

The development team then makes an estimate for each task-set. Such estimation is usually a collaborative effort, and may be done in many ways. Some of them are:

  • Triangulation, or comparing the task on hand with previous requirements, such as “Is this project bigger than project Y”, or “smaller than project X?”, and so on, to get an estimated idea of what it would take to execute the project. If the development team has a history of executing something similar in scope, scale and complexity, the task becomes even easier.
  • Polling, where each team member makes an independent assessment based on their experience and insights. Each such estimate is discussed in the group. The proposer defends the high or low end of the estimates as applicable, while the other team members act as the devil’s advocate. Finally, a consensus is reached after considering all individual estimates. This method is a preferred, as it is likely to reveal new information and insights. In the course of such polling, the user story itself may be modified in consultation with the client. In the absence of an immediate consensus, there is re-polling up to 3 times. If, at the end of third round no consensus is reached, they try to take a mean of the proposed estimates.
  • Fist of five, where the Scrum master develops an estimate in any plausible random manner, and puts it to vote on a scale of five to one, with five being “firmly agree” and one being “firmly disagree.” Team members have to not just vote, but also substantiate why they voted the way they did. This again reveals new insights. An estimate is accepted if it received an overall score of 3 or higher.

The net result is an effort estimate which will enable the team to decide how much work should be taken up in each sprint. The key consideration would be the velocity of the project team. An established project team would know their velocity, and as such the estimation methods become easier.

With a new team, with unknown velocity, it becomes difficult to make predictions. The way out is to either make educated guesses, or run a sizing iteration for the team to get a measure of its own velocity.

On the face of it, making estimates in Scrum may seem too much of a chaotic or ad-hoc in approach. However, far from it, such an approach actually reflects the realistic and practical nature of Scrum. Scrum sacrifices predictability for adaptability. When the business environment itself is uncertain and unpredictable, it makes little sense to be rigid and inflexible in making project estimates.

Author : Nayab Naseer Date : 28 Nov 2013