The Sprint Planning Meeting
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 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. Figure 1 shows the relationship between epics (large user stories that need to be further broken down), user stories (requirements) and tasks (actual work to be done to develop the user story). 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.
Figure 1: Backlog items
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 = 80 hours available hours per Sprint
- 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
- 630 total hours divided by 9 = 70 hours per 2-week Sprint for each developer
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
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 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
Key Words: Tasks, Estimation, Scrum
References:
Canty, Denise. (2015) Agile for Project Managers (Best Practices and Advances in Program Management). Boca Raton, FL: CRC Press
Cohn, Mike. (n.d.) Chapter 8: Choosing between Story Points & Ideal Days. Retrieved from http://athena.ecs.csus.edu/~buckley/CSc231_files/Cohn_Ch8.pdf
SCRUMstudy. (2016) A Guide to the Scrum Body of Knowledge (SBOKTM Guide.), 3rd Edition
Community Champion
