This blog represents everything agile. Agile thoughts, issues, concerns, experiences, etc. I want to share and provide an outlet for the agile mindset. "Don't just do agile, be agile".

### Recent Posts

Implementing Programs in Scrum

Regression Testing in Scrum

Planning for Uncertainty

Scrum Guidance Body Recommendations

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

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.

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.

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.

• 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

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

Posted on: September 09, 2018 12:37 AM | Permalink

 Network:15952
I think with all the story point counting systems, including fibonacci start losing their value as the point scale gets higher. So the best thing to do is keep iterations as short as possible thus reducing the need for a higher point on the scale.

 Network:2265
Thanks, for the installment, Denise.

Estimation in can be such a topic of debate. Absolutely agree with Sante. Best to keep stories as small as possible.

 Network:121950
Another great summary and highlights Denise.

Andrew, sometimes it is not possible to do the stories as small as possible so it depends on the situation.

 Network:2265
^ Agreed, Rami.
That was what I was implying with 'as possible' - denoting as situational.

 Network:7162
Thanks for sharing

 Network:719
Well done!

 Network:1788
Very interesting, thanks for sharing

 Network:2996
Denise, Awesome information on story points. Estimation is a biggest effort in the sprint planning session. In agile adoption it is one of the toughest job to come out from hours and days to story points. SAFe (Scaled Agile Framework) came up with normalization technique, which helped our teams in the estimation process. Thanks for sharing your thoughts!

 Network:37