Story Sizing — the good the bad and the types

If you’ve ever worked on an agile team you’ve talked at length about story sizing.

If you’ve never been involved it is the process of development teams giving a size to user stories, this can help (or hinder) various other parts of the team.

The good parts

I have to admit, I hate planning poker on teams — but there are some benefits that make it worthwhile

promoting discussion of the story
understanding of factors outside of your role that need to be considered
can help create a suitable workload
helps understand the balance of work on the team
we can split large stories into smaller chunks to deliver partial value
relative sizing helps us understand the different scale of stories

It can also help a team understand how much potential work they have in a backlog.

A good follow up is for the development and QA team to do tasks associated with stories. This helps to see how the points breakdown to different parts of the team.

Ceremonies like planning poker help us get consensus and promote the discussion of the stories.

The bad parts

With any process there will be downsides. A lot of the issues with points actually come from reporting in organizations.

estimates are taken as fact
we compare teams who might have different scales
reporting without context
discussion become arguments
teams can get drawn into delivering story points and not user value
Story splitting can happen prematurely (based on size, not on value)

The last point is a difficult one, if a story is too big we should split it, but we also need to understand the context. I’ve seen teams split a story in three (for size reasons) then still need to deliver the whole thing to achieve the end value.

Sizing, Sizing and well sizing

The teams I have worked on have used a couple of different methods of sizing stories, story points is by far the most common.

Story Points

Most of the teams I have worked on have ended with something like;

Story points = Complexity + Effort + The Great Unknown

Often when we size a story we don’t understand, or have undiscovered tasks . This allows us to undertake work without knowing the full detail of everything.

For sizing Fibonacci-like numbers are used — usually similar to: 0, ½, 1, 2, 3, 5, 8, 13, 21, 34, 100. I’ve found most teams will choose to limit this lower bound such as 13 or 21 as the gap between 34 and a 100 is too wide.

Teams generally get into a good rhythm with story points and start to size based on experience and previous work. This can be good for understanding future work.

For example we have four new API integrations based on past stories we know that this might be an 8 or a 13, so we understand the scale of the work.

T-Shirt Sizes

This is a little more lose generally teams use XS, S, M, L, and XL. What this might mean in a team is subjective, most of the time I’ve seen this as a high-level planning tool for future work.

At a team level, all that really matters is the gaps between them. Teams can also limit work undertaken by saying ‘We will only do one XL per sprint’, this might then be 2L, or 4M, 8S and so on.

Hours

We should… no, hours are awful — I’ve worked in enough agencies to see hours being jumped on tasks this usually masks a lot of issue as people feel compelled to put down time on a task.

No estimates

Do or do not, everything is only an estimate, your best guess, so do you even need to estimate?

I’ve always found on a mature team that sizing becomes less important, as a group the understanding of what an achievable amount of work is better understood, the benefits of good parts of estimating in the team happen naturally.