Estimation Techniques: The Sprint Planning Meeting

What Estimation Techniques can be used within Scrum Projects? The Sprint Planning meeting is the Scrum ceremony where the team estimates all tasks associated with each user story in the Sprint backlog. The estimation effort focuses on all resources required to complete the tasks for each Sprint. A shared task list is used to estimate the duration and effort for each user story in the backlog. This practice results in a shared team perspective, resulting in a task estimation process that is consistent and reliable throughout all Sprints.

Estimation Techniques

The most commonly used Scrum estimation technique is the practice of using story points to represent the value of a user story or task. This method is used for estimation based on the relativity of a backlog item to similar items. To be clear, many Scrum teams (Agile Scrum Master, Scrum product Owner and Scrum Development Team) use story points for task estimation, but it is much more common to use hours as the unit of measure for tasks.

A story point can be set for any value that a single Scrum team decides upon. Some teams assign the value of 1 week to a story point and other teams set the story point value to 1 hour or 1 day. There is no established value for a story point, however the value should be consistent throughout a Scrum project, or least within the same team. For example, if it has been decided that a story point has a value of 1 day, then 3 story points would equal 3 days. Story points do not measure how long it will take to complete a user story or task.

Story points are typically based on the Fibonacci sequence which is a number sequence where every number is the sum of the previous two. The sequence goes like this: 0, 1, 2, 3, 5, 8, 13, 21, etc. This technique is called Scrum Planning Poker where the Scrum team works to create accurate estimates. Planning Poker does not represent “hourly” estimates because a story point is an abstract measurement of size. Story points help understand relative levels of effort (LOE) for a user story or task in comparison to other stories and tasks.

Estimation Techniques: Decomposition of Tasks

The task list contains all assignments that are needed to complete the user stories in the Sprint Backlog. High-level tasks are decomposed into smaller tasks with greater detail. The level of decomposition should be sufficient to create product deliverables from the items on the task list.

Task Dependencies

Dependencies between the user stories and tasks should be evaluated, including those that are related to technical and staff availability. There are several types of dependencies that need to be discussed:

• Mandatory dependencies – This category includes dependencies that are for example, a result of contractual or legal related requirements. Physical limitations fall in this category and are referred to as “hard logic”, which are essential to the project work. An example of a mandatory dependency is completing work in a sequential order rather concurrently.

• Discretionary dependencies – This type of dependency represents those that are optional and are not required. The Scrum Team often considers discretionary dependencies as those that could be based on prior experience or best practices.

• External dependencies – These types of dependencies are based on tasks, products or activities that are outside of the scope of the project work and outside of the Scrum team’s control.

• Internal dependencies – These are based on tasks, products or activities that are within the control of the Scrum team. Basically, these dependencies are a part of the project work.

Estimate Tasks in Ideal Time

To recap, estimation criteria is expressed in two ways, story points (a measure of size, risk and complexity) and ideal time (a measure of time with no interruptions). The concept of ideal time describes the number of hours or days that are required to complete the work for the project’s deliverables. It is important to understand that ideal time does NOT include any time for work that is outside of the project’s scope. Ideal time represents the interval needed to do work without any interruptions (phone calls, lunch, meetings, etc.). Ideal hours are used to provide “time-based” estimates for development tasks. It is common that most estimates are excessively inaccurate where ideal estimates typically have realistic durations. Let’s look at how ideal time is calculated. We will look at ideal time in terms of days and hours. 9 developers on a Scrum Team

• 2 week Sprints = 10 ideal days
• The team works 7 hours per day = ideal hours = 7 * 10 = 70 hours per 2-week Sprint per developer
• The total ideal hours = 10*9*7 = 630 total hours of work for a 2-week Sprint

To summarize, ideal time represents how long a task takes if:

• The task being worked is the only task that a team member is working
• There are no interruptions while the task is being worked
• Everything that is needed to complete the task is available

Estimation Techniques: Elapsed Time

Elapsed time represents the total amount of time used to finish project work. Ideal time and elapsed time are not equivalent. If estimates were based on elapsed time, then ALL interruptions would need to be included.

There are several advantages and disadvantages in using ideal time:

• Using story points rather than ideal time is faster
• Ideal days can change based upon developers becoming more talented
• Ideal days can be distorted by actual days
• Discussions about ideal days are longer because of its potential unknown accuracy level
• One team member’s “ideal days” are not the same as another team member’s “ideal days”
• Ideal days are easier to explain to those that don’t belong to the Scrum team

The accuracy of the estimation can be discussed during the Sprint Review and Sprint Retrospective meetings in order to improve future estimation accuracy.

We found these books great for finding out more information on Agile Scrum: