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

  • 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

  • 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

Story Points

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

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.


No estimates

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

Different whale sizes

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.



front-end developer in Government into html, css, node.js and a11y. Co-orginizer of Frontend North East.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Colin Oakley

front-end developer in Government into html, css, node.js and a11y. Co-orginizer of Frontend North East.