Getting to the Story Points With Agile

This article explains some parts of the Agile methodology but assumes you have some knowledge about Agile and Scrum project workflow. No worries if not, I’ll be covering more of those topics in the future.

Abstraction as Estimation

Before going down this rabbit hole, it is probably best to quickly address what a story is. A User Story is a summary of a product requirement from the view of the end-user. For example, As a restaurant owner I want to be able to quickly reply to customer reviews so I can address customer concerns.

I’ll take a deeper dive on user stories in the next article. Follow me on Twitter or Linkedin for updates when it’s available.

Stories are the basic blocks of Agile project management. They are defined by the user value provided in a feature, as opposed to being defined by technical requirements. In Scrum, they are the work to be done per sprint. In Kanban they are the work in each phase of the board cycle.

In either methodology, it is common to assign an estimation of the work required to complete a story. This is the Story Point. Story points are a reference to the difficulty of completing a user story.

Story points are defined by a scale of difficulty and not by time. Rather than using a linear sequence of numbers (1, 2, 3, 4, 5), story points are best defined with a non-linear sequence of numbers. To explain, a non-linear sequence is a sequence of numbers that increases (or decreases) by an inconsistent amount. For example, common non-linear sequences are the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21…) or an exponential sequence (1, 2, 4, 8, 16, 32).

The reason for using a non-linear sequence is that it helps define scale of the difficulty in a story. A story with 13 points would contain significantly more risk than an 8 point story. This would not be as well conveyed in a linear sequence.

Story points are based on many factors including the complexity, risk, effort, and uncertainty of the user story. A due date is not considered in story points but the length of time expected to complete a story can be a factor in determining risk. More on this later, but the longer the time, generally the higher the risk.

Why should you use story points?

It’s possible you’re thinking this will add complexity or ambiguity to your current project workflow. Story points aren’t a requirement and there are teams that run Agile without them. However, there are things to consider before you write them off.

Story points are useful for newer teams or ones with high turn-over. They force conversations about and confirmation of the effort required to complete a story. Running sprints or a Kanban board without story points requires a strong discipline and experience within a team that takes time to nurture.

They also help signal when a story may be too broad and requires splitting into multiple stories. There will be a limit on how big of a story can be completed in a sprint. Using the Fibonacci sequence you would generally want to split up a story once it’s reached 13 or 21.

For the Scrum Master or project manager, story points are also useful in determining the teams velocity over a series of sprints. By averaging the number of story points completed per sprint over a series of sprints, the project manager can gain a metric of the repeatability of a team completing a spring on time. This is useful when establishing new teams and monitoring teams over time and through changes.

Edit: After some feedback, I want to add a reason you may not want to use story points. If your organization or management team struggles with accepting the fluidity and risks of estimation, story points may cause additional unneeded conflict. Story points are meant as an estimation tool and only that.

Getting started from zero

If you’re starting from scratch and want to implement Agile with story points for your project there are a few processes you need to get in place to get started. If you’re already running Agile, there may still be some tips here worth considering.

At the very beginning of the project, or at whatever state you’re currently at, you need to meet with the project owner to build an initial backlog of user stories and sort them by priority. You’re not setting points here. This exercise establishes what the user needs to gain value from the project and split those needs into manageable chunks as distinct user stories.

With the initial backlog ready, now it’s time to set the initial story points. In this meeting you need to involve all stakeholders including the Scrum master, project owner, development team, designers and anyone else involved in doing the work required to complete user stories.

Depending on the size of the backlog and the project team, the initial determination of story points could be a separate meeting or part of the initial sprint (or ongoing) planning meeting. In most cases it likely needs to be a separate meeting as it will take some time.

With a new team or project it can be tough for stakeholders to estimate points for difficulty as there is no reference. To help with this, start the meeting by having the team establish two or three stories that can be used as reference points. For example, have everyone come to an agreement on an example each for stories with points at 1, 5, and 13.

With references stories in place, now go through each story in the backlog. If your backlog is long, you should spend the majority of your time on the highest priority stories as these are the stories the team will take on soonest. The lower priority items can be roughly estimated now and refined in a later meeting.

A common method to help speed up this exercise is Planning Poker. Each story, starting from the highest priority to lowest, is explained by the Scrum master or project manager. Then, each team member individually raises a card with the points they believe should be assigned to the story. If there is consensus, the points are assigned to the story and you move to the next. If there is not consensus or there are questions or confusion about the story, then is the time to better define or break down the story into smaller stories.

Long haul

Once you’ve worked through establishing story points for the entire backlog your next steps are to plan the first Scrum sprint or begin pushing the initial stories through your Kanban process. As the team is working through these initial phases and into the future you will need to review and iterate on the process.

It is likely the team will eventually realize an active story was under or overestimated in points mid-sprint. It is best to not update the points and simply note the issue. If you remember velocity earlier, updating the story points mid-sprint hides mistakes that could become a pattern and would have been identified in the velocity metric.

Concerns or issues should be reviewed in sprint retrospectives and generally throughout the project, as needed. If there are consistent miss-estimations it may be worth considering having a backlog refinement meeting. This will allow stepping through the backlog again with a new perspective and experience with the project. The team may also need to modify the previously defined reference points.

As a Scrum master or project manager you will need to monitor patterns over time throughout the project to determine if adjustments or corrections are needed. As mentioned, velocity is a good starting metric to keep track of over time. I’ll cover this performance metrics in more depth in a future article.

I hope this was helpful in giving you a better understanding of Agile story points. If you have any feedback or questions, feel free to contact me on Twitter or fill out the contact form.