Posted by: jsonmez | 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 the sizing of stories 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 sizing of stories 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.



  1. […] Kanban Story Sizing, Elephants and Mice (John Sonmez) […]

  2. Hi,

    Couple of questions:

    1. So when does the team do the “estimation/ sizing”? With Scrum for example we do it at the beginnning of each Sprint during the Sprint Planning Meeting.

    2. If there is like an “Estimation meeting”, who does the sizing? I’ve heard about teams consisting of 20 people. I can’t imagine 20 people sitting in a room doing the estimation right?

    Cheers, J

    • It depends on the approach. There are several ways of doing it.

      1. Don’t do estimation. Just have the product owner understand not to mix elephants and mice. Adjust as needed.

      2. Pull together estimation meetings as needed. Since Kanban is about flow, you don’t need to schedule estimation at a repeating interval, just when a certain number of estimated backlog is left.

      The less overhead the better.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: