Why your story point estimations are too low
1, 2, 3, 5, 8, 13, 21, …, ∞
I think we can all agree that estimating story points is much easier in theory than it is in practice. Usually, the difficulty in estimation comes from either a lack of knowledge/experience in story estimation or (worse yet) an inability to come together as a team to reach a consensus.
One of the main issues that I constantly see over and over again when a team tries to estimate a particular story is the tendency to drastically underestimate the complexity. We all do it, we think we are smarter than we really are, or that a particular new feature can be implemented more quickly than it realistically can. Even after the estimation process is over we tend to struggle equally as much when deciding how many stories we realistically think we can complete in an iteration.
I think one of the primary reasons that our point estimates are notoriously low is that we do not account for communication complexity. We always focus on how hard the problem is from a technical perspective and completely ignore everything else.
To illustrate my point, I will share an experience from my previous project. The first two iterations were geared specifically towards building a greenfield ASP .NET MVC 4 application. This is something several people on the team were famaliar with and, as a result, the story estimations were exceptionally accurate. We ended up making every one of our velocity goals and the entire project went swimmingly through the completion of the site.
However, once we got to the tasks that required interaction with resources outside of our group we effectively saw our velocity grind to a halt. We were wasting oceans of time running around trying to coordinate efforts between groups to try and complete tasks that –from a technical standpoint– were far easier than most of the work we did on the initial web site.
We hit this issue because we were not properly considering the communication complexity associated with a particular story, only the technical complexity. If we had taken a few steps back when estimating each story and identified which resources we would need to interact with outside of our group, then we would have given each of those stories a much higher points estimate even though they were easier in nature. This would have allowed us to use our previous velocity to better estimate the number of tasks we could complete in an iteration and saved everyone involved a ton of frustration.
For some teams, this might seem daunting since the story estimation process is already so tedious and painful that you couldn’t imagine adding anything else to the process. If this describes your situation, then I would suggest starting out by implementing a generic rule of thumb that any story which requires effort by someone outside of your group gets an automatic bump to the next fibonicci number. By doing this you will create an objective requirement that everyone can follow and it could end up meaning the difference between the success and failure of a project in the long run.