Just a few weeks ago we received a message from the good people at Spartez (spartez.com), who have some impressive experience in building tools for agile software development. For those who don’t know, Spartez has been working closely with Atlassian for the past ten years. The proposal was to visit them so they can show us their products and so we could discuss the possibility of delivering even more value through agile tools to the world of software development. It doesn’t take much time for a rebel to take on such an opportunity. A short flight to Gdańsk and we were shown the products and features in Spartez’s headquarters.
FORGOTTEN KNOWLEDGE
One of the products that we saw was a planning poker tool. The process itself was born in 2002 and it was not “designed” but rather “discovered.” The author James Grenning was facilitating an XP release planning meeting with two guys going back and forth. They found the rest of the team not engaged. It is sometimes funny when you observe teams still doing this 15 years later. The planning poker tool was James’s practical solution to stalled planning meetings. But I think there is specifically one important thing that most teams are still missing while using planning poker and, therefore, they are not making the most of it. The original planning poker employs story points, not time-based estimates. So yes, it was intended to estimate with relative numbers, sometimes referred to as triangulation. People are just so much better when comparing items to each other. Imagine you and your team are given a task to estimate the number of beans stored in jars of different sizes so you know how many beans you have in total. One approach would be to come up with an absolute number for every single jar. But I am sure that after a while your team would start to compare the jars to each other and they wouldn’t have much trouble assigning them relative numbers: “This jar is twice as big as the first one.” Just like in planning poker, at least how it is supposed to be…
HELPING YOUR DISCIPLINE
So why do development teams use relative estimates so rarely? My experience is that using relative estimates demands much more discipline. With absolute numbers, you are kind of ready anytime. You look at the jar and you simply give your best shot. That’s it. But with relative numbers, you need to put all the jars on the table and, quite often, some representative to compare them to. Carrying these representative jars to a planning or backlog refinement session is simply too much trouble for many teams. You need to spend extra effort in choosing the representative and you have to make it transparent for the team. If you happen to use Jira for your backlog management, you may end up with multiple web browser tabs looking for different backlog items to compare to while running a planning poker session. You may also choose to prepare a paper version of your (Jira) backlog and while this is usually my favorite, it is also the most time consuming. Teams spot such inefficiencies very quickly and if they are unable to resolve them, they are very likely to abandon triangulation in favor of absolute estimates and/or even abandon the whole group estimating process. And this is where a well-designed tool could help you quite a lot.
SHARPENING THE TOOLS
Unfortunately, many existing tools supporting estimation promote absolute estimates as they don’t offer the teams a convenient way of using triangulation. This was the case with Spartez’s planning poker tool when we first saw it. We had a great discussion with Spartez’s engineers about agile planning practices and estimation. They were very open to our feedback about their product and they decided to tune it specifically to make it easy to use relative estimates. If you use Jira for your product backlog management and you have ever tried group estimating with triangulation, you might want to give this planning poker tool a try. Speaking of group estimating, we were very happy to see that the tool supports it very nicely as this is essential in the planning poker process. You do know estimation is a group exercise, don’t you? Read on.
THE WISDOM OF CROWDS
There is yet another somewhat forgotten value of using planning poker. Many experiments have been run that prove that groups of people estimate at least as good as experts, if not better. I believe this has been widely recognized since the release of “The Wisdom of Crowds” by James Surowiecki. I wouldn’t say this is always true and I have been in software development long enough to acknowledge its complexity. Still, there are really not too many arguments against using the wisdom of the team, aren’t there? I’ll give you an example. One of the teams that I have been working with recently decided to try planning poker for their estimates. Imagine how much fun we had when we quickly discovered that our expert, who used to do all the estimates himself, produces estimates that are four times shorter than the rest of the team on average. He was just so optimistic and so confident. However, he’s not the person who will eventually do all the work. Ultimately, it will be the team.
IT’S ABOUT PROCESSES AND TOOLS THIS TIME
“Individuals and interactions over processes and tools”. There is a big chance that if you are reading this blog post, you know what this means. I feel I have been blessed in a way. Most people that I have worked with over the past years either already have been living their professional lives by this rule or were about to very soon. Sometimes with just a little bit of a helping hand. Agile has been around for a while in the software development industry and even though nobody has ever claimed that processes and tools are evil or superfluous, my feeling is that they have never been given enough attention by the agile community. There has simply been more emphasis on the importance of people’s mindset. To this day, I find that just too many product owners and development teams are not satisfied with their tools and processes and they are not sure where to look for help. Well, if they already have the agile mindset, they should be able to achieve their goals regardless of what tools and processes they are using, right? I tend to disagree. You see, it is like telling people that breathing is more important than eating and then not giving them food. Guess what? You need both.