So far we’ve highlighted a few antipatterns of story point estimation that you should be aware of. We’re now concluding this series with a callout to the most common traps to watch out for while using this estimation style.
Trap 1: Assigning points to every activity
Many XP teams often give points to all their activities – even those unrelated to the core activity of writing code. You’ll see them creating a 1-pointer for a meeting or another 2-pointer while coordinating with someone, and so on. This is problematic because not only are you tracking everything you do, but you are calling it velocity!
The real purpose of velocity, we reiterate, is to show how much your team can do in a given period of time. And this “how much” is essentially how much software you can build. At the end of the iteration, you should be able to sum up all the completed stories and say that the team can do 10 points (for example). You should then progress to discussing possible impediments, overcoming them, and ways to improve velocity.
Tip: Keep points to only about writing code
Velocity must strictly be about software and writing code – never about how many meetings you attended or emails you sent, even if those are important activities. If you give points to all the activities done in your 8 working hours, the velocity will only highlight the fact that you put in 8 hours a day or 40 hours a week. There will be no insights into how much software you’re able to build in that period, thus obfuscating the purpose and value of velocity.
Trap 2 – Accommodating QA estimates along with dev estimates
At some point, even mature XP teams find themselves in a scenario where someone engaged in a supporting activity to development, most commonly QA, will question how their time requirement is getting accommodated in the overall estimation. The QA may be looking at a story that’s complex to test even if it’s simple to develop. They know they will need more time than what’s been estimated and raise a flag. They may ask for a larger size for that story, and denying them that could lead to ill-will in the team.
In such a case, should the devs do one estimate and the QAs do another and you add it all up? No! That’s the worst way out, because this will instantly kill any relativity you may want to maintain in your backlog.
Tips:
Consider only the dev estimates
The Theory of Constraints advises estimating the bottleneck, which is typically writing code. What a PM or a BA or a QA does is valuable, but it’s only writing code that should figure in your estimation. You can assume everything else will be proportional to that. A story that’s larger to build will naturally be more difficult to analyze or test or deploy into production. So, keep it simple, and estimate only the development.
Treat exceptions as just that, but investigate trends
However, your backlog can have stories that need to be treated differently. A story may require complex analysis even if its algorithm or logic is simple to implement. Or there could be a type of story that’s quick to do, but its impact is across several different places and testing will be arduous. Our advice here is not to worry about such exceptions. Size is based on pure complexity and your velocity will reflect that that particular story took longer although it was not very complex.
However, if you see many stories that have disproportionate effort compared to complexity, then it needs attention. Ask yourself questions like: Is there an opportunity for automation in the face of multiple manual changes? Can we restructure the code such that we follow the DRY (Don’t Repeat Yourself) principle? Investigate such patterns thoroughly and address them at the right time.
Adjust capacities of the team to meet exceptional challenges
If you are building an application that needs to work across multiple device sizes and browsers, then, potentially, testing can be more complex than development. Some teams may argue that their constraint is testing rather than development and a way to resolve that would be to estimate the testing effort and assume that development will be proportional.
While this is the correct response theoretically, it might be an unfamiliar and difficult approach for many. Instead, adjust capacities of roles in the team. In the above example, you could add more testers to take care of the various devices and browsers and work it in such a way that development complexity remains the constraint because that is what people are familiar with.
Trap 3 – Spiking with no limits
Spikes are small experiments that you could do when you don’t know the answer to something or how to implement something. For example, you’re integrating with some third party component and you know so little about it that you can’t even estimate the time it will take. To arrive at that estimate itself, you may want to first play around with that component. That is spiking. Spikes have an important role to play in the project lifecycle. But it’s critical to not let them turn into endless rabbit holes.
Tips:
Time-box a spike
Manage spikes by time-boxing it. Allocate a definite time period and at the end of that, you should know what to do next. Since at least one of your developers will be playing that spike for that period instead of working on a production story, take that capacity away from your velocity and make adjustments. Velocity commitments for that particular iteration could be lower than usual because of the spike.
Assign a size to a spike
You can also use points. We’ve worked with the thumb rule that any spike should be a Small. While it is cheating a little because we are in a way associating size with the time expectation, it does help limit the time that people could spend on that spike.
Trap 4 – Creating stories for supporting activities
An extension of the above trap is that some teams create a separate story for activities that will eat up a developer’s time – such as technical analysis or proving out the best strategy with testers, etc. All this is time consuming, but it’s distinct from writing production code.
Tip: Call them tasks, not stories
We insist that stories be used only to represent code that’s getting built. That must be the sole definition of a user story. Call anything else that will require a developer’s time as “tasks” and call out that the team will be short of capacity in that particular iteration.
Trap 5 – Creating 0-pointers
We’ve seen previously that as you become familiar and efficient at completing stories, you subconsciously start downsizing them. This behavior can leave you with 0-point stories (downsized from a previous 1-point). Despite its seemingly negligible size, the story will still require time and effort. But you’re discounting the velocity for that because it seems too small to even count. This leads to a tricky situation: your productivity has improved because you are getting better at your work, but your velocity does not reflect that.
Tip: Keep in sight the original sizes you started out with
Keep a reference set of stories that have the original sizes from your first estimation exercise. Compare your current set to those and then bucket them in the correct and relative sizes. This will avoid random 0-pointers that you think require no time, but add up to the velocity.
Trap 6 – Making the velocity math work…somehow
Often you may convince yourself that you will protect your velocity commitment no matter what; that you will sum up all the activities that add up to that velocity and somehow make the math work. What that really translates into is that you’re shying away from critical conversations. If you find yourself spending more time today doing tech analysis, for example, it could be that complex features are the trend going forward. You then need to talk about addressing that trend by adding developers or calling in relevant experts if required.
Tip: Engage in right conversations at the right time
Surface the issue for the whole team and the stakeholders so you’ll get more options. Even if the options are not viable, at least there will be clarity about the nature of work that will go into building your software right. At all cost, refrain from contrived efforts to make it to the velocity numbers. It will not reveal the true state of the project and prove detrimental.
The key takeaway
Be vigilant at all stages of the project in order to catch downward trends. Agile strives to uphold transparency, clarity and visibility in the project and your way of working. Having meaningful conversations as needed will ensure these attributes. This will go a long way in successfully forging a solid relationship – strongly rooted in trust and reliability – with your client stakeholders.