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.
Bonus: Whales
We once joked that we would use whale sizing in a retro, so we need Killer (XS) Minke (S), Humpback (M), Blue (L) as our standard sizing metric.
Why not? At the end of the day use whatever works for your team, think about what you are doing and what you are trying to achieve.
