≡ Menu

FASTER Fridays – Relative Sizing

Happy Friday! This week’s #fasterfridays touches on one of the more challenging parts of software development – estimation. We talk about Planning Poker, and then touch on Team Estimation which approaches estimation from a different perspective with the same goals. If you’re interested in finding out how to apply this to your organization, don’t hesitate to reach out via Twitter or email hello at coryfoy dot com. Have a great weekend!



Happy Friday! Welcome to this week’s FASTER Friday. When I first created Mapping Mondays and Faster Fridays, I knew I was creating a commitment to be able to deliver two videos per week. That commitment wasn’t based off of a wild guess – I had an idea of how long things would take – estimates if you would.

In our teams, we also want to be able to understand what we’re able to commit to. There’s a large variety of ways of doing this – from Cycle Time to Story Points both of which I have articles I’ll link to. Interestingly both methods require a form of sizing – for Story Points to get the actual story point, and for Cycle Time a way of understanding different sizes of work flowing throughout the system to know what our expected Cycle Times are.

Unfortunately, the primary way we talk about sizing work is using Planning Poker. Planning Poker – which is a great exercise – is where a team has a deck of cards following the modified Fibonacci sequence – 1,2,3,5 and so on. They then pick a story from the backlog, read it, discuss it, and then vote on it by each member picking a card and then everyone showing their card at the same time. The lowest and highest then talk about their perspective and there’s a revote, with the goal to get consensus.

However, while notionally we use this as a sense of relative estimation and sizing, the mechanics require us to already have a notion of time mapping in our heads. So instead I try a Team Estimation game which removes points completely until the very end. Here’s how it works.

We still start with some backlog of work we want sized, and we still pick the stories up one by one and discuss them. But then instead of voting on story points or t-shirt sizes, we lay it down in a column. We then lay the next one either below, to the left or to the right of the first one, depending on if we think it’s about the same size, smaller or larger. We then continue going through this process until all of the cards are in columns.

At this point, if we’re primarily focused on flow and cycle time, we can ask whether there’s enough difference for us to track them separately. However, if we want story points, we can now use planning poker to size each column, instead of each card.

What’s nice about this method is we have the ability to insert columns during the initial process, or consolidate at the end. Basically we can focus on the cards and how much work is in them rather than trying to map to a specific pointing process. We also don’t have to be strictly linear in our sizing of our columns.

So if you or your team find yourself struggling to size work, try not sizing it and merely placing it instead. It might help drive out the conversations around the items, putting the focus on collaboration instead of points.

If you’re interested in more, I go a little more in-depth in a some blog posts on sizing, even sizing in Kanban. I’d also recommend checking out Mike Cohn’s “Agile Estimating and Planning”

Hope you’ve enjoyed this. Feel free to check out all of the FASTER Friday videos on my blog, and if you’d like more information do reach out on Twitter at @Cory_foy or via email at hello at coryfoy dot com. And be sure to come back next Friday for another Faster Fridays video!