Yves Riel acts as a Scrum Coach to help teams learn the Scrum methodology. Yves has actively been using Jira and GreenHopper since 2009. He built Rekall for Jira to help agile teams improve their estimates.
Every year, I try to make an appointment with my doctor for an annual check-up. Invariably, I walk out of his office with a blood tests form in my hand. These tests are what helps my doctor notice illnesses like high cholesterol or diabetes. About two years ago, I began to suspect my agile team was suffering from a different disease: Estimation Disorder. Unfortunately, I had no tools to diagnose the problem like my doctor, so I started to keep track of some data. After a few weeks, I plotted the distribution of the time spent executing the issues versus their story points value. I also extracted statistical data such as the minimum and maximum time spent on issues as well as their average and standard deviation. These graphs became an invaluable tool in my fight against my teams’ Estimation Disorder. This article will show you some of the pathologies that can be discovered by looking at the graphs’ profile.
“Story Point Favoritism” pathology
After a while, some teams start to lose perspective and see everything to be the same size. Hence, they end up having one or two favorite Story Point values. This pathology is relatively easy to diagnose. When looking at graph, you see that the distribution of some Story Points is disproportionate with respect to the others. The most common symptom is that almost all the new items in the product backlog are estimated at the same Story Point value. The team may also experience a fluctuating velocity since there are too much differences in the time required to execute the stories. This will especially hold true if your sprint includes user stories that are in the lower and higher percentiles of the distribution.
In order to be an effective estimation technique, Story Point values must follow a linear trend. When it is not, the extrapolated date for the completion of the product backlog may be completely off. If your team has success planning and executing smaller user stories but struggles with the bigger ones, it may suffer from the “Exponentiality” syndrome. To confirm this diagnostic, look at the graph and try to locate a big jump in the data. The text book pathology is for a team to exhibit a very good linear trend for the smaller Story Points (0.5, 1, 2, 3 and even 5) but to diverge considerably for higher Story Points. It is as if these higher Story Points would fit the trend much better if pushed further to the right. If the velocity of teams exhibiting this pathology has been based on sprints containing mainly lower Story Points items, you should use extreme caution in calculating a product backlog completion date; especially if the backlog contains many higher Story Points user stories.
This pathology gets its name from Venn diagrams. Venn diagrams are useful when you want to see if an item actually belongs to different data set. Therefore, the graph of teams displaying this pathology will show a large overlap over two or many Story Points. It is not uncommon for teams to start developing this pathology after being pressured by management to increase their velocity. The team will then subtly increase the Story Points value of stories over time. After a while they can start claiming more Story Points per sprint but they fail to realize that similar items were previously executed at a lower Story Points value. It is also very common for these teams to have their velocity greatly fluctuate sprint after sprint.
Just what the doctor ordered
If you diagnose your team to suffer from one of the above mentioned pathology, do not despair. With a little bit of work and patience, they can be cured from their affliction. The prescribed remedy is to recalibrate your Story Points benchmark and start using Triangulation. However, just like blood tests, you should run these checks on your team periodically since you never know when they can have a relapse.