White elephant sizing game with Hanoi Tower algorithm

Estimation is one of the first stages of a project realization process. Clients want to know how much their projects are going to cost, and Product Owners want to know how much time they need to carry out a given project. Usually, the difficulty level of doing an estimation by a team of developers is directly proportional to the size or complexity of the project. However, such process should be a part of every business project.

I’d like to share our experience with the modification that we’ve come up with for the task estimation method — “white elephant” — which has significantly speeded up the estimation process, especially when it comes to large projects of the Java team.

Some time ago, a new lead appeared. The Java developer team had to make an estimation. We chose the white elephant method. In this method, we prepare little cards with user stories’ titles that we have to estimate. The cards are put on the table and then they are sorted according to their difficulty level, following specific rules. This way, we save time by not voting separately for each user story, and at the same time, we control what particular user stories look like in comparison to others.

White elephant modification

Before starting an estimation, we divided the project into several dozens of user stories, which had been written down on the cards. The estimation of such a big project and the high number of tasks posed a great challenge to us, that’s why we decided to use a quick estimation technique, and we chose the white elephant method. Five developers took part in the estimation. Each element was randomly assigned to groups numbered 1, 3, 5, etc. story points.

In the beginning, the estimations went well, but at some point, we noticed that for some tasks opinion was divided, which made them constantly change their positions in the sets of a given score. If there are tens of tasks in one column, it is difficult to pick out the cards which continually change their positions.

The estimation session started to drag on, and the team still had not taken their decision about many tasks. What took most of the time was reading the descriptions of each functionality.

Since we are programmers, we decided that the whole estimation process needs to be optimized and our work must be quicker. We came up with the idea that the tasks we move to another group will be always put one on the other, like in the Tower of Hanoi algorithm.

Hanoi Tower algorithm

Now I will describe the Hanoi Tower algorithm for those of you who haven’t heard about it. In the Hanoi Tower, there is a specified number of towers and disks of various sizes. Every tower contains disks of different sizes. You must put all the disks in one tower, from the largest one to the smallest one, moving them from one tower to another. You can only put smaller disks on the bigger ones. Below, you will find a simple animation illustrating the process.

How does it help us? The tasks about which we all generally agree naturally stay at the bottom. The lower the task lies, the more confident we are that the members of the team agree how time-consuming it is.

What next?

After several iterations, we decided to cut off the tasks from the bottom. We assumed that if a task had not changed its positions for some turns, all the developers had become acquainted with it and agreed with its estimate. Thanks to that procedure, a big number of tasks started to disappear from the tasks sets. The session began to move on faster. Soon, we eliminated the tasks we agreed about and left those which we disagreed about.

After many iterations, only some of the dozens of tasks remained on the table and we knew we had to talk more about them and concentrate better on them.

In the case of tasks which had too many unknown quantities or for which there was no estimation agreement, we adopted the most pessimistic option of the estimate sets where the user story card was frequently laid.

Sometimes in private life and everyday situations, a programmer’s experience can prove useful when it comes to solving more or less complex problems we encounter. In our case, the problem was the prolonging estimation process of a complicated project. Borrowing the Tower of Hanoi scheme to the White Elephant Method considerably accelerated the estimation session.

Summary

Since the first time we used our variation of the White Elephant Method, we have often employed it when we needed to make an estimate. The estimating process is getting much shorter and we are easily able to pick up the tasks which keep moving between the different story points sets. This lets us know that a given task may be difficult or too complicated to understand for some of the team members and it must be split into more manageable chunks.

Hope it will be useful for you and if you have any questions just drop me a comment below.

Originally published at xsolve.software on July 11, 2016.