Week 1.10: Agile Development – Stories and Story Points

As we mentioned in the last post in the Working with Agile series, stories are the main workhorses of Agile Development. Stoies are what we load into our sprints, stories are what the team works on and stories are what the team delivers once their work is complete. Delivering all the stories in an Epic completes the Epic and likewise for Features too.

In this post we will look at how stories are constructed and present a realworld example of one as well. We will also look at the estimating or sizing stories so we understand how easy or difficult they are to work on and deliver.

To help the team the Agile community has produced a convenient template for creating user-centric stories, often referred to as User Stories and follows a format similar to these:

This frames the requirement from the end-User’s perspective in terms of WHAT they want and WHY they want it.

The golden rule is if you cannot write a User Story to capture what needs to be done, you probably don’t understand the requirement fully.

With the User Story complete, the team then estimates or ‘sizes’ it to give an indication of the amount of work and degree of complexity involved. Most developers I’ve worked with are notoriously bad at estimating and even worse as recognising it. Their estimates are usually very optimistic resulting in delays in the project because days turn into weeks and weeks into months.

Agile addresses this through the use of an abstract quantity known as Story Points . Several different flavours of story point exist: modified Fibonacci, integer power of 2 etc. and my preference is for Fibonacci.

Rather than attempt to assign a time or duration to a story, the story point system uses a number from a defined sequence (in the case of Fibonacci this is 0, 1/2, 1, 2, 3, 5, 8, 13 etc.). Increasing numbers represent increasing complexity so a story with 3 points is more complex/difficult than a story with 2 points and less complex/difficult than a story with 5.

When assigning points, the team will discuss and decide together, as a team. This allows each member to contribute based on their own knowledge of the system, the story and their experience. Once technique I have used with great success in the past is Planning Poker. After a brief discussion, each team member holds up a card with their impression of how easy/difficult the story is. The highest and lowest numbers are discussed further in case someone either hasn’t understood or knows something the others aren’t aware of then the team draws again until consensus is reached.

It is important to note that story points cannot be added. If a story is split into smaller stories, the points do not need to add up. For example if a smaller story (e.g. 1- or 2-points) is split from an 8-point story it will remain an 8 and will not drop to 5 until enought work has been split from it to bring it to the size of a 5.

List of Images

Figure 1. THORN, 2020 Story Template

Figure 2. THORN, 2018 Story Sizing

References