What’s the Point?

Story pointing or story sizing is the art of putting a number against a story that would indicate how complicated a piece of work will be. These numbers are the “points” that ultimately feed into statistics that determine your sprint team’s velocity and capacity. It’s an essential part of the Agile process, yet, many teams don’t adhere to the spirit behind these “points” and so they lose their meaning. That has knock-on effects as well. As a Scrum Master you won’t be able to determine your team’s velocity because it’ll be all over the place, and you won’t be able to plan ahead for your future sprints.

Even worse, some teams have fallen victim to the demands of others (looking at you, Project Managers) who want to use story sizing as a means to plan “how long” a piece of work will take. In those cases, story points become a reflection of “hours” instead of anything else.

So, let’s avoid all that and ensure our teams are using story sizing and pointing as intended – with the help of this guide.

What are points based on?

During refinement sessions, after having gone over the story requirement and various acceptance criteria with the developers and testers, the team considers the story based on three things; Uncertainty, Complexity and Effort. Based on that, the team can put a score (or point) next to the story.

Uncertainty refers to the unknown aspects or details of a story. If the team decides during refinement that even at the best effort of the story writers that there are still some details that will only come forward later, that will increase the level of uncertainty on the story.

Complexity speaks to the nature of the story and the technicalities the team will face when developing and testing the story’s requirements.

Effort is an indication of how much work will need to be done to get the story across the line. A story might be quick to develop, but impact an array of items that will need to be retested. This means a large amount of effort would be required to develop and test the story. Effort could be viewed as the time it would take to complete the story.

Fibonacci. Is that a type of pasta?

To make sure everyone doesn’t use their own scales and metrics for these scores, there are a couple of themes you can choose that are widely used in the Agile community.

Fibonacci Sequence (1, 2, 3, 5, 8, 13, 21, etc.):

The Fibonacci sequence provides a natural progression of increasing values, reflecting the uncertainty and diminishing precision of estimating larger stories. It encourages the team to focus on relative sizing rather than absolute time.

The larger values in the Fibonacci sequence may introduce more ambiguity and subjectivity into the estimation process. Large gaps between values can make it challenging to differentiate between high-effort stories.

T-Shirt Sizes (XS, S, M, L, XL, XXL):

T-shirt sizes are intuitive and easy to understand. They provide a quick and rough estimation without getting into too much detail. This scale is useful when the team needs to prioritize items without getting into precise effort estimations.

T-shirt sizes lack specificity, making it difficult to measure and track progress accurately. The scale may not provide enough granularity for teams working on complex projects with varying levels of effort.

Powers of 2 (1, 2, 4, 8, 16, 32, etc.):

Powers of 2 allow for a clear progression in estimating effort or complexity, accommodating a wide range of story sizes. The scale helps in highlighting the exponential growth of effort as stories become larger.

Smaller values in the scale may not provide enough granularity for smaller or simpler stories. The scale may be less intuitive for some team members who are not familiar with binary concepts.

Customized Scale:

Some teams prefer to create a custom scale based on their specific context and needs. This can be a linear scale (1, 2, 3, 4, etc.) or any other scale that suits the team’s preferences and provides the desired level of granularity.

A custom scale may require additional effort to define and understand its nuances. It may also limit the team’s ability to benchmark or compare estimates across different projects or teams.

You have a scale, now what?

Based on our experience, most teams use two scales. They use T-Shirt Sizing to give big, overall estimations on stories usually at the beginning of a project. When it comes to more refined, accurate sizing, the Fibonacci Sequence provides you with a scale that’s both flexible and easy to use.

The discussion now revolves around relating the scale and its points (1, 3, 5, 8 etc.) to those areas of consideration we spoke of earlier; Uncertainty, Complexity and Effort. As luck would have it, we have a neat little diagram for that to explain to you, your team (and Suzanne from marketing) how you got to those points.

“But this only shows points going up to 13!” – I hear you screaming. Well, that’s where one of our pro tips comes in. If your team feels the need to size a story beyond 13 points, that should be an indication to your team to explore splitting the story into smaller stories.

This isn’t a strict rule, but we have found that it prevents massive stories from clogging up your backlog and it motivates and reminds the team to keep stories simple and achievable in a single sprint. Like they should be.

A word on Baseline Stories

Through your journey on understanding story points, you will more than likely come across some person referencing the words “Baseline Stories”. Don’t panic. Baseline Stories are simply stories that your team has worked on before, where they are 100% in agreement on the size given to that story with the power of hindsight. You can then use these selected (baseline) stories to reference against the stories that you are actively sizing. We call that “relative sizing” because you’re comparing something that you’re sure of against something that you’re not sure of yet.

The benefit of using baseline stories is that it allows you to add a little more accuracy to your story estimation. The drawback is that not all teams work on stories that are similar to one another, or, more often, new teams starting out don’t have the luxury of referencing stories that have already been done, because those don’t exist yet. The other drawback is that teams change throughout projects and a previous 8-point story would not be applicable to a team consisting of newer members.

In my personal experience, I have found it to be far more consistent to size any story based on those 3 criteria; complexity, uncertainty and effort. Using the table above is a great way to make sense of story points for the entire team. As the team grows and becomes more sure-footed with their work, the story points will also find their natural flow in the team.

Puh puh puh pokerplanning

Many teams use another event called “Poker Planning” to get points assigned to refined stories. This is a really efficient and fun way of getting the points agreed upon assigned to stories by making everything a little more guided and interactive.

We recommend a tool offered by Kollabe over at Kollabe Planning Poker

How it works is simple:

• A scrum master hosts a room, or session and sets up the poker board with whatever points scheme the team uses.
• The scrum master then shares the link to the room and everyone with the link can access it.
• Items are added onto the board (we usually use the Jira links to the stories) and “players” get to pick a card ranging from 1 – 40 written on them.
• When everyone has put their cards (or votes) on the table, the moderator can flip the cards and reveal what folks have voted. This results in an average number or, in some cases, further discussion if the points (or votes) are all over the place.

There is a free and paid-for version. Using the free version is more than sufficient for most teams, but the paid-for version offers a few more advanced tweaks for teams that really want integrations with Jira etc. Overall, it’s well worth it in the end.

Story Pointing / Refinement Tips

• Story points are not a commitment. Many teams like to use points to determine how many sprints a piece of work will take to complete. That’s not a great idea because points are best-effort estimates based on complexity, not time. It does, however, provide the team with a view of items in their backlog that might be larger than anticipated, so prioritization is facilitated through that aspect of sizing items.
• All members of the team are welcome to size items. You shouldn’t solely rely on input from experienced or senior members when sizing stories.
• Remind yourself that the aim of a refinement session is not to get points assigned to stories, but should always be to ensure the team is on the same page when understanding the acceptance criteria of the story.
• Be careful not to turn refinement sessions into “story writing” sessions. If a story is not fit to be refined with the team, it needs to be done outside of the refinement space. If input from the developers and testers is required to even write the story, it needs to be done outside of refinement sessions.
• Timebox stories so that you can make the most of your refinement sessions. Questions are welcome and strongly encouraged during these sessions, but spending 30 minutes to refine 1 story, might indicate that it’s not quite ready for refinement.
• Create a shared page or Confluence page that lists the stories you intend to refine in your next refinement session. Let your story writers own and contribute to this page. Make sure everyone in the team has access to it to allow them to digest some of the information that will be presented beforehand.
• Using a list such as that mentioned above is a great way to keep track of stories and allows you to circle back on the ones that could not be refined previously (especially if you noted down why they needed to be skipped).
• If you’re using Jira, remember to add corresponding labels to your stories to mark them as refined or not-refined. You could move them to a special place in your backlog as well once refined. That’s a whole new conversation, but make sure you do the necessary admin during refinement sessions. If you have the paid-for version of PokerPlanIT and have linked it with your Jira instance, it does a lot of the admin on the fly. (Don’t be lazy, do it yourself).

So there you have it. Background on story pointing (or sizing) as well as a method to the madness to help your team assign points to stories in a consistent manner that actually means something.