Skip to main content

3, 2, 1 - REVEAL POINTS. The true value of poker sizing

Many of us are in teams with a good habit of sizing work items, and in many cases this is a good habit. However, do we truly understand the importance of this behaviour? Why do we do it? Is it even necessary, and where is the real value of all this?
A Royal Flush, the highest possible hand in poker: Source Wikimedia Commons

Points poker sizing is very common. The team calculate velocity and use this velocity to forecast their work for their next work iteration. Some environments have different pressures than others so a forecast doesn’t need to be that accurate.

There are many environments where calculating a forecast isn’t important, or set iterations (sprints) aren’t used (those teams using Kanban or pull methods of delivery). In these environments: Is it worth sizing at all? Many teams also find sizing time consuming. A few hours a week of sizing, means a few hours a week taken away from delivery.

Several years ago the ‘no sizes’ movement was picking up traction because of this assumption. I differ, I think sizing is important not only for forecasting, but to establish a shared understanding of work to be delivered. Differing sizes between team members, suggests inconsistent understanding in the work item to be delivered. As such, a healthy sizing session would bring this lack of understanding to the surface so that all team members are fully synced up with the assumptions and constraints that the work-item is written with.

Stick with sizing even if you’re not using it to forecast. It creates a shared understanding of requirements and this in turn will save time in delivery. Eventually If you find that Fibonacci points isn’t working for you (maybe because of its high level of granularity), maybe it’s time to use an alternative method of sizing such as bucket or T-Shirt sizing.


Popular posts from this blog

My first time speaking at a conference

Since time immemorial we humans have valued the art of public speaking. Today, I want to share with you my experiences in speaking at conferences for the first time. Recently, I spoke at both DDD Melbourne and DDD Perth. Both of which were positive experiences that I learnt a lot in.

from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that's new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn't have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

Context and agile practices

At times we have competing responsibilities - ship code or don't ship it because of a small edge case bug; put pressure on our team or make the business happy; coach our friends or write code.

This is a normal part of our everyday professional lives, and it's important to strike a balance that will help us in the future, but also deliver in the short-term.