By June 21, 2010

Kanban Story Sizing, Elephants and Mice

In our morning standup meeting one of my team members made a pretty good point about story sizing not being so important.

In Kanban we strive to have relatively same sized stories because it allows us certain benefits:

  • More accurate metrics on estimated time in queue for any story to be delivered.
  • Reduced dependence on estimation and planning.
  • Continuous flow as opposed to slow… fast… fast… slow.
  • Predictability.

I thought you said the story sizing is not so important?

Right, exactly.  It is important for them to be relatively same sized, but it is not so important that they be exactly the same size.

Basically, we don’t want to have mice and elephants thrown in together.


It is the difference between breaking a candy bar in half to share and measuring out prescription medication.

You can look at the candy bar and say “yeah, that looks about the same size,” but you’d better not do the same thing with medication.

It is a complete waste of time to go overboard with the splitting of the candy bar, getting it even to the exact milligram.

It is a complete waste to try and get stories estimated down to the hour.

Size ‘em up against each other

In that case how do you actually size the stories?

Just compare them against each other.  When looking at a new story, consider the other stories you already have on the board.  Is this new story like an elephant in comparison to a bunch of mice?  Is it the other way around?

If so, adjust the story to make sense.  Don’t trust your gut without comparing it to what is out there already, otherwise you’ll start to drift in your estimations.

Don’t worry too much if you’re wrong sometimes.  As long as you are close, it will all balance out in the end.

Also don’t forget to get rid of all the Blue Whales.  You don’t want any of those on your board, ever.

About the author

John Sonmez

John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."