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.

Comments

Popular posts from this blog

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.

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.


Have You Ever Produced Negative Value in a System!?

As developers we encourage our product owners to order the priority of their backlog in order of value. However, every time a new feature is implemented by a development team, there is a certain degree of risk associated with the introduction of that new code. Namely, risk of breaking another part of the product and maintenance cost. When a development team pulls in a new feature to implement there is a certain acceptance of this risk. In many cases, the risks that arise due to additional code complexity doesn't justify the value added by the new feature itself, so the development team can start implementing it.

Are there scenarios where the value added to a software product can be negative though?