Step 5 - Story Pointing

Overview

A Story point is a metric used in agile project management and development to estimate the difficulty of implementing a Story. There are a variety of ways to do point estimation and Shortcut allows you to edit your Estimate Scale to meet your needs. This section goes over how the Shortcut team does and recommends doing Story pointing, but if your team already has a way to Story point that is working well then of course keep it up!

Shortcut leverages Story points in order to:
- Help us determine a realistic amount of work for each iteration/sprint cycle.
- Ensure that we only work on bodies of development work that are small and well-understood.

We use Story points to represent complexity (not time).  We use a Fibonacci sequence (1, 2, 3, 5, 8, 13…) to assign points to Stories.  

*Points are the best way to signal that a Story is too big and needs to be broken down. Estimating by hours is less ideal because an engineer with more experience could take 40 minutes, for instance, while another engineer might take 4 hours. Their estimates will be wildly different. However, the Story’s complexity would still be the same. This is why Shortcut, and many other folks use Story points to represent the complexity of the Story.

Our Story Point Scoring

• 0 points: We do not use 0 points in our process - even for a task that may not require development time, it will still require someone’s time and energy. So that we can account for all work we’re doing, we assign all stories at least 1 point
  
• 1 point: A very straightforward task with NO unknown risks.
  Example: Copy change in a place where we’ve changed copy before.
• 2 points: A pretty straightforward task, with a low risk of an unknown or unexpected complexity cropping up.
  Example: Creating a new tracking event in our system, which is a task we do consistently.
  
• 3 points: A mildly complex task and/or some unknowns that may cause an increase in complexity as we build (but we have a pretty solid idea of how we will approach the work).
  Example: Returning a new response in a payload for the frontend to consume, in an API we have worked in before.
  
• 5 points: A more complex task and/or a solid amount of unknowns that will eat up time while the task is worked on.
  Example: Building a small feature in a part of the code that we may be unfamiliar with.
  
• 8 points: A pretty complex task and/or a task that is mostly unknowns.
  Example: Building a feature in an area of the code we are unfamiliar with or that may have dependencies with other squads.
  

*Note that we do not assign more than 8 points to any 1 Story.  If a Story is more than 8 points we break it down into smaller parts.  In general, we also try to avoid 8-point stories unless the work absolutely cannot be broken down any further or better understood.

Assigning Points to Stories

We use pointing poker (the StoryPlan plugin for Slack) to assign points to Stories during our Refinement process. Every other week, we hold a 1-hour meeting with the entire squad. We go through the Stories, in order of priority (assigned by product) one by one in the following way:

• The stakeholder who wrote the Story gives a brief overview of the Story.
• The squad asks any clarifying questions to help us better understand the work required.
     a. If any small adjustments are needed, we make them live on the call.
     b. If the squad does not have enough information to know how we will tackle the Story, then we will turn the Story into a spike/research Story.  That spike Story will be worked on first, and will result in the creation of a new Story, with better define criteria for how to complete the work.
• Once we have exhausted questions, the team uses StoryPlan to vote on the Story points.
     a. If the votes are within 1 step of each other (e.g., if all the votes are between 1 and 2 points) then we select the higher points (so in this case, we would assign the Story 2 points).
     b. If the votes are more than 1 step apart (e.g., the votes are split between 1, 2 and 3 points) then those who voted for the high and low scores would make a case for their point assignment.  Once the discussion is complete, then we re-point the Story.

Auto-Assigned Points

We have 2 types of stories that are automatically assigned point values (no voting):

• Bugs: We automatically assign bugs 3 Story points. This is because it is hard to know how complex a bug will be until we actually start to dig into the code.  If the bug begins to expand beyond 3 Story points worth of work as someone works on it, then we flag that and re-evaluate.
• Spike/Research Stories: We automatically assign Spike stories 3 Story points.  This acts as a timebox for how much time should be spent on the Spike.  If more research is required after the 3-point allotment is complete, then we re-evaluated and potentially create another Spike Story to continue research.

Using Points to Plan our Iterations/Sprints

We use Shortcut’s reporting features to determine how many Story points our team was completed during our 2-week Iterations.  After about 3 iterations, the team found out they were doing around 40 points per Iteration (for a team of 6 developers, with varying levels of experience).
‍
At the start of each iteration, we measure the team’s capacity for that iteration (remove any out-of-office days, vacation days, etc).  We then assign a proportional amount of points to the iteration based on the team’s capacity.  For example, if the squad's capacity is 70% for an iteration, then we would assign 28 points for that iteration (70% of the 40 total points).

The team will go through the last iteration and move any stories that were incomplete to the upcoming iteration and assess if any others were complete that were not already marked as Done. Then stories are assigned to the iteration based on points and capacity. Any stories that were not added to the upcoming iteration will be moved to the next and reassessed at the next pointing/iteration planning meeting.