Improving The Process Of Estimating

Introduction

At Mapudo, we follow the SCRUM framework to plan and build our software. This includes meetings like sprint planning, dailies, backlog refinement, sprint review and retrospective which helped us become a better team, provide a better predictability to share- and stakeholders as well as keeping the stress out of the development team.

In this article we don’t want to talk about how SCRUM has helped us or what SCRUM is. Instead, we want to focus on how we solved certain obstacles regarding processes in the SCRUM framework or to be more precise: The process of estimating.

The Beginning

When we started estimating our stories (we are a pretty young company) we did it in a really basic way. One person would guide us through the stories of the next sprint, story by story, and on the count of three, we would all just raise our fingers with the appropriate story point count. The first issue we faced was that we had no idea in which way to relate our estimation to previously estimated stories. Sometimes a text change was a 1, sometimes a 0.5, and so on.

The next step was to find stories which can be used as a reference in order to argue WHY something was a 1 or a 3 when estimating. This helped us having consistency in our estimation and velocity and improving our commitment. However, we still faced the issue of having to raise our fingers — especially since we were using the Fibonacci sequence — to estimate. Try showing 13 fingers, you won’t be able to (probably). The solution was fairly simple and is probably known by most of you. Planning poker!

It’s basically what we did with fingers, just with cards. Way easier, of course. This worked out for a couple of months until we hired a new developer who exclusively works remotely. Video conferences had delays so we weren’t able to estimate at the same time. But we didn’t even get to this point, because one of our developers had a great idea!

Going Digital

We started to estimate our stories with https://www.planitpoker.com/, a tool, which allows you and your team to play online from anywhere you want to.

Whenever a story has been discussed in a SCRUM meeting and was deemed ready, i. e. “Definition of Ready” was checked off, we pasted the link of the story into this tool. After discussing all tickets, we started estimating in the development team. The tool helped us extremely well integrate our new employee without letting him feel disconnected from the rest of the team but there were still some minor issues with this tool. Firstly we had to paste every ticket manually into this tool, so copying the URL (or ticket id) and pasting it into a list. Secondly we also had to copy the final estimation from the tool back into Jira. This led to a lot of hassle, copy-pasting and sometimes skipping an estimation. But these were all acceptable issues since they were minor and the tool was still more of an advantage than a disadvantage. But at Mapudo, we’re always trying to improve the way we work in an effective manner, so another developer had another great idea! As you can see, employees can always suggest new ideas and shape the way we work to the better.

Improving Digital Solutions

So what was the idea you ask? As you probably already noticed, we use Jira; not only for our stories, but also for roadmaps, communication and many other things! So, we simply went to the market place of the Jira apps and searched for “Planning Poker”. Yep, it’s that simple. The first result was this tool right here called Planning Poker which works for both Jira Cloud and Jira Server.

This tool did not only offer the same advantages as planITpoker, it also got rid of all the disadvantages. When creating a new game, you can simply say that you want all stories of the upcoming sprint which are not estimated.

This helped us getting rid of the problem that we had to manually copy over each story that we wanted to estimate

After the game is started, the Game Admin is able to select a story that shall be estimated. The next view shows

• the story that is currently being estimated
• all possible story point estimations (you can select the type, e.g. Fibonacci when setting up the game)
• the total amount of estimated points during this game
• what you previously estimated as “x”, i. e. reference stories
• the votes of all players as well as the average vote after everyone is finished

As you can see in the list of features that this simple screen has, we also solved the issue with reference stories. No longer did we have to update our reference stories, since the tool always takes the last five stories with the same estimation which also reduced our time effort.

But we won’t stop here, the tool also helps you transferring the data back to the Jira ticket. Once everyone has estimated, Planning Poker calculates the average (which you can override) and with a simple click on a button you can transfer the estimation to the ticket. This greatly increased the speed in which we estimated our stories and also helped us not forgetting transferring the story points!

Conclusion

Our way was rough and started with a simple analogue solution. If we wouldn’t have hired a remote software developer, we would probably never have searched for an online alternative which led us to using one directly integrated into Jira. In the past year, we greatly increased our efficiency, not only for the estimation, but also all the organizational work surrounding the estimation, such as transferring story points to stories, selecting what to estimate and updating our reference stories.

After a few sprints of using the Planning Poker Tool, we can recommend it to everyone who wants to improve the estimating process. We’re sure you will not be disappointed! If you are interested in the tool see the video to get to know the full list of features.