A Guide to Story Pointing

Growing up, you may have been told that it’s not nice to point. If you weren’t told that, well - it’s not nice to point. Except when it comes to agile software development. Then you want to exercise pointing quite frequently.

In agile project management for software development, a story point is a useful metric to determine the difficulty level required to complete a story - in other words, how much effort is required to complete a story.

This differs from waterfall, or other traditional approaches to project management, which focus instead on the amount of time a project will take.

Before we delve into story pointing, let’s review what a story is in the agile software development process.

In Shortcut, we define a Story as representing an individual piece of work to be completed in a Workflow, which can be broken down with subtasks. A Story is the fundamental unit of work in the Shortcut hierarchy.

As such, assigning points to Stories is the best way to make sure work is being distributed efficiently. It can also signal when a Story is too big and needs to be broken down into smaller units of work.

Story pointing allow teams to:

• Determine a realistic amount of work for each sprint cycle
• Ensure you’re working on bodies of development work that are clear, well-understood, and small enough to undertake in a sprint cycle

Why is Estimating Work by Effort Better than Estimating by Time Spent?

Story points should represent complexity, not time. Why is this? It’s because estimating work by hours can vary wildly from engineer to engineer.

For example, an engineer with more experience could take 40 minutes to complete work, while another engineer might take 4 hours to do the same thing. Either way, the story’s complexity would still be the same. This is why it’s best practice to use story points to represent the complexity of the story.

Who Benefits from Story Pointing?

Story points in Agile benefit development teams and product owners alike and allows them to work together more efficiently. And maybe even make them like each other.

Read More: How to Get Software Engineers and PMs to Like Each Other

For engineering folks, the dev team gets a better grasp of what’s required of them, making it easier to develop a sound implementation strategy. It also helps them not over plan, so they’re more likely to finish a unit of work; when the team knows how much to plan in a sprint, they can work at a sustainable pace. The team can also create a reasonable estimate without having to commit to a specific timeframe.

Read More: Software Engineering Teams are More Productive When They Work at a Comfortable Pace

PMs, conversely, can better assess an item’s ROI and value. PMs can also better understand the technical risk associated with their more oversized items, while also forecasting the product’s longer-term delivery.

Estimating Story Points

Calculating story points means estimating the total amount of effort involved in making a particular feature or functionality go live so that it can deliver value to the customer. If you're having trouble estimating a Story or the scope of work is overwhelming, your story might need breaking down into smaller parts, and you may need to split it up across multiple stories.

To estimate the total amount of effort involved in a story, your team will need to discuss questions like: How complex is the work? How much work is needed? What are the technical abilities of the team? What are the risks? What parts are we unsure about? What do we need in place before we can start or finish? What could go wrong?

We use Shortcut’s reporting features to determine how many Story points our team completed during 2-week Iterations (what we call sprints). After about 3 Iterations, our found they were doing around 40 points per Iteration (for a team of 6 developers, with varying levels of experience).

Read More: How to Prioritize Work When There’s So Much to Do

Assigning Story Points in Shortcut

One way to explain assigning story points is to walk you through how we do it at Shortcut. ‍

At the start of each Iteration at Shortcut, 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.

Many teams use a Fibonacci sequence (1, 2, 3, 5, 8, 13…) to assign points to Stories.

Here’s how we do it at Shortcut:

• 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
  

At Shortcut, we don’t assign more than 8 points to any one Story. If a Story is more than 8 points, we break it down into smaller Stories. In general, we also try to avoid 8-point stories unless the work absolutely cannot be broken down any further or better understood.

Read More: Ultimate Setup Series: Best Practices for Iterations

Who Assigns Story Points?

At Shortcut, 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-Assigning Story Points

In the Shortcut app, 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.

Story Pointing Takeaways

Here are a few things to keep in mind throughout the story point estimation process:

• Story pointing is a process. You’ll keep getting better. After each sprint, take stock of what went well and what didn’t in a retrospective, and aim to improve your story point estimation. Learn and make adjustments.
  
• Break down stories that are too large. When story pointing, if you find that you’re consistently hitting the highest numbers allowed, it’s time to break down stories into smaller units of work to make your sprints more successful.
  
• A good project management tool is a must. There is no such thing as assigning points effectively without one. In addition, using Shortcut, teams can plan and build continuously and simultaneously. Everyone can jump in and create Stories, assign tasks, connect Epics, and agree on Milestones no matter where they are in the tool. For example, a product manager can turn any text in one of their Docs into a Story, assign that Story to an Engineer, and their original documentation will be kept automatically up-to-date whenever the Engineer updates the Story with the progress on their work.
  

Read More: The Shortcut Way

Try Shortcut

Give Shortcut a whirl for free. We're project management for entire software development teams - without all the management. But with all of the pointing.