In the previous blog post I already gave you my opinion about estimations. In that blog post I discussed the idea of whether or not you should estimate, this blog post is a bit different as it focuses more in the individual tasks and tickets and whether or not to estimate those.

I wasn't expecting to write this post, since it never occurred to me that you should treat different tickets different based on their type. However, I have worked on projects and in teams where they did exactly that. So before we dive into the details, I first need to clarify the different types used to differentiate work.

• Task: something that needs to be done but doesn't add new functionality and most often doesn't even involve changing code. Examples of this are setup of pipeline, environments but also code formatting.

• Bug: something is broken and needs to be fixed. It doesn't add new functionality but corrects something that doesn't work properly.

• Feature: adds new functionality to the application.

• Spike: investigation, research, proof of concept of how something could be done. This does not add the actual investigated feature or change to the application.

With these different types identified, we can now think about reasons why you would not estimate them all, or estimate some of them differently.

Tasks and features are typically estimated in story points are form the basis of the iteration, features even more so than tasks. This is the norm for many projects I have contributed to and lead to the standard poker game to come to an estimate the team can agree upon.

Bugs are a different story, I have had projects where bugs were not estimated. The idea behind this is that fixing it should be covered by the original ticket where the feature was implemented or the bug was introduced, and thus be part of that estimate. The argument here is that adding an estimate on bugs inflates your velocity, but I would argue the opposite. Not adding an estimate on bugs causes your velocity to be unstable. Iterations with many planned bug fixes cause them to be over-committed, as in the end all the time you spent doing the actual bug fixes is not taken into account and thus you need to do more work in less time. In the end I don't think it will matter that much since velocity should be a self-regulating system that settles after a while.

Another reason to not estimate bugs is that it is more difficult to do so. You know something is wrong, it doesn't do what you expect of it, but it is much harder to estimate what you need to do to fix it. In the end if you knew what you needed to do, the bug probably wouldn't be there. This means that an estimate on a bug fix is less reliable than an estimate on a feature or task.

The same goes for a spike. How do you even estimate some research work? Instead of using story points, I have seen projects using a fixed time boxing approach. Instead of estimating the spike as 2 story points, it is limited to 1 day of work for instance. But what do you do with the spike? Do you leave out an estimate or do you 'translate' the time-boxed value to story points? You can't simply add a value in days to the values in story points, as story points should not be directly related to time. Again the issue of velocity comes into play. Not adding an estimate value causes fluctuations in your velocity which is not good.

If in the end the goal is to have some certainty about when features or bugs are done, you need to estimate all these tasks. Having estimates in different units makes it hard to make predictions, not estimating certain tasks also makes this more difficult. To make predictions about the future, your velocity is a crucial tool, but if this tends to fluctuate a lot from iteration to iteration, it doesn't help that much.

As I have mentioned in my previous blog post, estimating is a very difficult task. We have been doing it for years, and we often don't get any better at it. So be careful with whatever you decide, and see whether it makes sense or not. What value do you get out of it? What are the benefits of doing it like that and would doing it another way add value? This highly depends on the environment you are working in and nobody can tell you how you should do it.

What do you think? Do you estimate everything? Do you estimate them all using the same unit? What is that unit? Have you ever thought about doing it a different way?