Why does Pivotal Tracker discourage estimating points for bugs and chores?

Question

Pivotal Tracker "strongly discourages" estimating velocity points for bugs and chores – you have to change a setting and accept a warning to be able to do it.

They explain why here, but I just don't understand it. Here is an excerpt:

By measuring velocity in terms of features only, Tracker can estimate how much real, business-valued work can be completed in future iteration, allowing you to predict when project milestones might be achieved

Chores and bugs take time. How can ignoring this help you to predict when a milestone will be reached?

Say you need to complete three more features to get to the next milestone, and you also need to complete a chore (because one of the features can't be started until that chore is done)... How could discounting the time needed for the chore help you to estimate when the milestone will be reached?

Answer 1

I know this thread is a little old now, but as a developer at Pivotal, I don't completely agree with any of the existing answers.

The philosophy behind not estimating bugs isn't that bux fixing doesn't deliver business value, it's that introducing a defect into the app and then fixing it does not represent net forward momentum.

For example, let's imagine that two teams are implementing the same feature set on iOS and Android. The iOS team has bug/chore estimation turned off, whereas the Android team has it turned on.

The iOS and Android teams both estimate the same story at 2 points. They both finish the story in the same amount of time, but in the next iteration, it turns out the two teams have introduced bugs with their implementation.

The iOS team has only introduced one bug. They fix it in an hour.

The Android team has introduced three bugs, and assigns them one point each. It takes them a day and a half to fix them.

The iOS team is moving faster than the Android team, but Android's velocity is now higher. This throws off the planning of future iterations, making it appear as if the Android team is moving more quickly towards a viable release, when in fact they may be introducing bugs into their implementation at a faster rate than the iOS team, and therefore accomplishing their goals more slowly.

Sometimes, however, there are defects which were not introduced by your team. Maybe it's a legacy codebase, and the defect is as old as the hills. In this case, it doesn't make sense for this story to drag down your velocity, and you should probably log it in Tracker as a new Feature, rather than a Bug.

Of course, it's ultimately up to you how you want to do story estimation. I've worked with a few teams who had bug/chore estimation turned on, although I personally prefer to have it turned off. Tracker won't judge you!

Answer 2

"Feature Velocity" vs. Capacity-Based Scheduling

Pivotal Labs is making a marketing decision with this design choice. By addressing themselves to "business value" as the key metric, they are implicitly discounting the importance of tracking team capacity or project scheduling in a broader sense.

Another way to look at this is that they are trying to sell a dashboard for management targets rather than iteration planning. The Pivotal Tracker FAQ says (emphasis mine):

By measuring velocity in terms of features only, Tracker can estimate how much real, business-valued work can be completed in future iteration, allowing you to predict when project milestones might be achieved[.]

So, their idea is that bugs and chores aren't "real" work and don't add value. I disagree, but that's the point that they choose to make with their target audience. They also seem to discount the idea that bugs and chores consume team capacity, and assume that the cost of these non-valuable tasks can be amortized over time, leaving management free to focus on setting targets for milestones.

They also say:

In contrast to features, bugs and chores tend to emerge over time, and while they are a necessary part of your project, they can be thought of as a constant drag on business-valued output - an ongoing cost of doing business.

In other words, rather than make the cost of bugs and chores explicitly visible to the project, they discount them in order to provide a management dashboard that is more focused on feature-delivery than capacity-based scheduling. In my opinion, this prevents proper control of the project's budget and team resource constraints, but there are clearly people who disagree.

Enabling Points for Bugs/Chores

In fairness to Pivotal Labs, they do allow you to disable this misfeature. You can allocate points to bugs and chores, with the caveat (dire warning?) that it's an irreversible decision for the project.

While discouraged, it is possible to enable estimation for bugs and chores, in project settings. However, it is not possible to revert that setting once your project has any estimated bugs or chores.

Personally, I generally recommend that all tasks chargeable against a project's budget or that consume team capacity be made highly visible and properly accounted for. With Pivotal Tracker, the choice is yours.

See Also

Rather than invalidate the accurate quotes and links above (you can probably still find the original in various Internet archives), here are the updated Pivotal Tracker links that contain more or less the same concepts but with different wording and updated instructions for changing how the system behaves from its defaults.

• Planning with velocity
• Bugs and chores aren’t estimable by default
• Bugs and Chores May Be Given Points

Answer 3

You should estimate bugs and non-functional requirements

I am not familiar with Pivotal Tracker. However, looks like your question is more general:

• Should I not be estimating bugs?
• Should I not be estimating technical debt or non-functional requirements? I think this is what you are referring to as "chore".

In my opinion, you should be estimating these. Pivotal Tracker seems to be taking the view that only "features" deliver value to the customers. I would argue that fixing bugs in production improves user experience and delivers value. See here for more. The exception to this is if bugs are found in completed stories in the functional/regression testing or even the post-release stages, they should be fixed by the developers who introduced them, without getting any point credits for the same.

Similarly, if you improve performance, stability or security, that also improves user experience and delivers value. See here for more.

By not estimating these, you sweep these under the carpet, and you run the risk of piling up bugs and technical debt.

Answer 4

Another interesting point is that in order to estimate a bug, you have to understand why it's not working, and that's usually the longest of the work.

So it can take a lot of time and speculation for the estimation.

What we did without Pivotal Tracker was calculating and "average value" (based on the time it took to fix the bug, transformed into points), so we would always give this value to bugs (and sometimes have big differences with the reality, but they compensate with time, as we re-adjust the bug value each sprint.