Sizing user stories is a key part of understanding the overall effort required to create a product release. Getting started is simple: pick a baseline story and assign a number of Story Points or Ideal Days that it will take to complete the story. Next, look at other stories in the backlog and decide whether or not they are bigger or smaller than the baseline story and by how much. Lather, rinse, repeat.

Developers coming from waterfall teams are accustomed to doing time-based estimates. Junior or intermediate level developers were usually asked to estimate functionality that was well-understood and broken down into small units of work. But in waterfall efforts, sizings done during project inception were probably done using a high-level estimation technique such as function points by a more senior analyst, lead and/or architect. Agile user stories are not necessarily well-defined or split into small stories the first time that they are sized (they will be by the time they are brought into a sprint plan). Because of this legacy of thinking in terms of hours to build, developers often revert to using a time-based estimation technique when trying to size user stories.

Before we go any further, some quick definitions:

Story points: a points scale (possibly using the Fibonacci sequence – 1,2,3,5,8,13,21,etc.) that indicates the size of a story relative to a baseline story.

Ideal days: the number of days of effort that it would take the team to get a story done if the team worked with no interruptions.

Once the team has sized the baseline story, it is ready to start comparing other stories to it and assigning points to them. But along the way, developers may develop an ‘algorithm’ for assigning Story Points. You know they have done this when one of them says, “I think that story will take 8 hours, so it’s a two-pointer.” What is happening is that the developer is doing a time estimate of their effort and reverse-engineering the story points rather than sizing the story relative to other stories. This is when the ScrumMaster needs to remind the team about the goal of sizing stories and why Story Points are a better approach than a time-based estimation approach.

Story Points are for sizing, not for time estimation. This allows teams to:

1. Quickly size features and create a release plan without getting bogged down in implementation details. Team members are often very reluctant to provide time estimates unless they have all of the details about a feature. Being agile means that it is okay not to have all of the details up front. Developers typically are more comfortable saying that Feature B is twice as big as Feature A knowing that they won’t be held to a specific time estimate.
2. Use Story Points in conjunction with the team’s velocity to make delivery date projections that are not as prone to decay as those using story-level time estimates. Relative sizings based on Story Points are usually fairly stable; estimates based on time can change dramatically as a project unfolds. In conjunction with Story Points, velocity is a reflection the team’s productivity and expertise. This is much easier and more flexible than trying to bake size, effort, productivity, and expertise into one ideal days number for each story.
3. Create sizings that include all of the effort to get a story to ‘done’. Story Points include development hours, user interaction design, QA testing, etc.
4. Prevent stakeholders from using Ideal Days estimates to calculate unrealistic delivery dates which are then mandated to the team. It is not their call how many hours per day the team spends actually working on user stories. They do not have a sense of how the mix of skills on the team or other factors will impact productivity. It is up to the team to determine how much time it can spend working on stories, and how much time it needs for grooming the backlog, doing production support, etc.

Reflections

• The team should size the backlog without having deep, detailed requirements conversations.
• Story Points are a way to size features without having to calculate how much time it will take to do the work.
• Story Points are less prone to decay than Ideal Days.