If you are working for a company that follows the Scrum methodology, this post will be familiar. If you don’t, then you’ll probably see how you can introduce it into your work.

One of my favourite books, which I found when I started coding, was “The art of doing twice the work in half the time” by Jeff Sutherland. He was the co-creator of Scrum. The book introduces the reader to Scrum and gives you the backstory and examples of how it is everywhere.

So what do I want to discuss today? 

Well, that is sizing user stories.

It’s a critical skill in Scrum. The benefit of sizing user stories is that it enables a team to look at a work and envision the complexity and time that a user story will take. 

But how do we do it?

Well, Jeff writes about how it originates from basing user stories on dog sizes. Yes, that’s right. The team sit down and look at a user story. Let’s say we’re creating a login form for a website. Let’s start with three user stories:

1. UI for the login form
2. Authorisation
3. Build a database to store user details

Now sizing is not based on picking a random number (or dog breed in this case!). A good practice is to compare stories to each other. For example, after a short discussion, the team decides that the most complex story out of those three would be the third one, building the database. They label this one a Great Dane.

Next, they agree that the least time-consuming task is going to be creating the user interface. They have similar forms on the website, and in comparison to the Great Dane user story, this one is simple. This user story is the size of a Chihuahua.

If we now have the most complex story and the most straightforward story, we have one more story to consider: authorisation. The team discuss it. As a team, it is agreed that it is less complicated than building a database from scratch but more time consuming than the user interface. 

However, there is disagreement. One team member has done this many times in a previous role. They are confident in their skills and suggests that the story is the size of a poodle. However, this is new ground for another member of the team. At the same time, they agree that it is not as complicated as creating the database, but it will take time for them to figure it out. This team member suggests it should be the size of a Border Collie.

The critical value of Scrum is transparency, so this allows for a team discussion. The higher and lower estimator can explain the reasons behind their sizing, and the team can agree or compromise. 

Another thing to note is that if the team agrees to size a user story at a considerable size, the team should discuss breaking that specific story down further.

Finally, although we use dog breeds in this example, there are several options:

• Fibonacci sequencing
• T-shirt sizing

However, no matter the option used in your workplace, the logic remains the same; you compare the stories and base the sizing on the complexity.

I hope this post helped to introduce you to user story sizing, come back tomorrow when I’ll continue the Scrum series!