There has been a great deal written about relative size estimation and its many benefits: simplicity, speed and adequacy commensurate with the level of planning. Despite all that, we find that adopting relative size and story point estimates by teams is not without its challenges. This blog covers some tips to coaches for getting teams to examine it, try it out and see if it would work for them.
Team members, their managers and leaders early in the agile journey may feel uncomfortable with the notion of relative size and may even think of it as yet another agile fad. They may have been estimating in hours for quite a long time and it may well be working for them – sprint and release goals being largely met consistently. So, what is the immediate additional benefit of relative size estimation, they ask. So, how does a coach get teams & other stakeholders better educated about relative size estimation and its use cases for a more informed decision on its adoption?
As an introduction, listen to my conversation with my PM Power colleague J.Veeraraaghavan (JV) on the subject:
Tip #1
Managers, architects, product owners and product managers are often the folks very much involved in release (or PI) planning. In many cases, they are likely to be planning in person days even at such a high level of planning – based on their experience and gut feel. However, many of them will readily admit that they do not get adequate feedback on what they planned versus what the team was actually able to achieve over a period. A simple (if somewhat abstract) common output measure is the need of the hour. Story points can be that common output measure – that spans the many levels of planning, providing feedback to the higher levels of planning. This potential benefit usually vibes with the leaders to at least give it a try. Also, if the teams participate at least to some extent in the higher levels of planning, they too would begin to its value in action.
Tip #2
In some cases, the next quarterly planning may be some distance away and weekly backlog refinement sessions that are closer at hand may be good opportunities for the leaders and teams to get introduced to the relative size concept and practice it first-hand. Start it in a trying out mode – not as a big bang plunge.
Tip #3
There is an inverse relationship between the time invested in backlog refinement for the next sprint and the time for the actual sprint planning for that sprint. If not enough time & effort is put in for the backlog refinement, the subsequent sprint planning session would be very time consuming and not effective. Team members may not fully understand the work & commit to sprint goals. So, the tip is to get the team to invest more on backlog refinement. And the “currency” for backlog refinement sessions relative size & story points rather than endless & highly subjective estimates of hours & days. Needless to say, the exercise is most useful when the team is trying to get a sense of sizes of a bunch of related stories (“relative” right?) rather than isolated enhancements. And collectively as a team in a “planning poker” kind of a session.
Tip #4
In practice, some teams may take to relative sizing more easily than others. As in the conversation with JV above, component teams doing specialized, firmware and infra kind of work tend to push back – for good reasons (such as comparing “apples” and “oranges” in their work mix). In general, coaches need to address their specific challenges to the extent possible. But, as always, it is the team’s decision to try it out and decide.
In conclusion, bear in mind – relative size and story points are not always a substitute for effort estimates at a team level. I would say that relative size estimation and discussion as a team result in more educated individual effort estimates, forecast completion dates and very importantly, improve their ability to estimate.
Having said all that, nowhere is it said that agility mandatorily means relative size and story points!
