Cheat Sheet for Story Point Sizing – by ResponsiveB

As teams in Agile move towards Relative Estimation rather than Absolute Estimation, they often struggle in understanding the science behind this technique and hence end up giving just “numbers” to the user stories.

Teams should also understand “Why” should they size relatively before going into the detailed “How” and “What” parts. User Stories are the smallest unit of Value Delivery to the customer and represent part of the Working Software. Therefore they are relatively sized in Story Points (the scale being used 1,2,3,5,8,13) and not time. As a definition, STORY POINT is a unitless measurement of the size that encompasses the 3 parameters of a user story – COMPLEXITY, UNCERTAINTY and EFFORT.

Also, it is important to note here that the above-mentioned scale represents SIZE and not ESTIMATES for the approximate completion of work in focus. For ESTIMATES, you would need the historic VELOCITY (or a guess if starting for the first time) of each team. Interestingly, I have observed that most teams end up equating story points to time (for eg. 1 story point = 6-7 hours) and run it like an anti-pattern.

Once teams start estimating user Story Point estimation through Poker Planning, another observation that I have seen is that too much discussion happens when the scores are not in consensus. The idea is to have a common understanding of the user story across the team on all aspects and not just focus on the number.

Keeping this in mind, I have prepared a cheat sheet that can help teams look at the three parameters – Complexity, Uncertainty and Effort. This can help the teams to embrace Relative Estimation for better story sizing.