Should bugs be story-point estimated?

Question

Devs in my team state that estimating points for a bug that needs investigation is not beneficial as it is too difficult to assess the difficulty of fixing a bug before actually laying hands on it.

They also endorse the idea of having a drop on sprint velocity when fixing a lot of bugs as a reflection of "we had a lot of not planned things to work on", and aiming to have Story points as a measure of planned work speed.

I, on the other hand, think that story points should be given to everything that we put work on, also bugs: that way, if we spend a sprint only fixing bugs, the velocity is not 0.

I guess, in short, the question is, how do you approach bugs from the agile, point estimation approach?

Answer 1

There's no one right answer.

I'm not entirely sure that I'd buy the developers' argument that it is too difficult to assess the difficulty of fixing a bug. The very same argument could be said about any change to a system, yet it seems like they don't have a problem estimating other types of work. Even implementing a new piece of functionality could have ripple effects that may not be noticed until the work starts. Unless someone is using the team's estimates as targets or plans, I don't think that this holds up.

Rather than having a conversation about story points on bugs, I'd rather have a broader conversation. The purpose of estimating work is to help the team plan their upcoming work. In Scrum, that is to help the team plan their Sprint. There are also some side effects, like helping the team ensure that everyone tends to be in agreement about the scope of work. What does the team need to do in order to effectively plan a Sprint? An effective plan includes a Sprint Goal that the team is likely to achieve by the end of the Sprint and a set of Product Backlog Items selected for the Sprint, some of which support the Sprint Goal.

It doesn't matter if the team estimates in story points, ideal hours, or not at all. The team needs to be able to commit to a Sprint Goal that is developed as a collaboration between the Product Owner (representing all of the stakeholders) and the Developers. What they do to ensure that the Sprint Goal commitment is reasonable and likely achievable depends on the team. Different organizations, stakeholders, and teams may also have different levels of risk tolerance.

So, story point bugs. Or don't story point bugs. Or stop estimating. Or, even better, let the team run an experiment. Let the team not estimate bugs for a few Sprints. Can they still make and commit to Sprint Goals? Are they able to effectively plan a Sprint and deliver value for their stakeholders? If they can, then maybe they don't need to estimate bugs. If they struggle, try an experiment and have them estimate bugs. Does it help? You should have your answers in 2 or 3 Sprints.

Personally, I've worked with teams that were very successful with only estimating new features or requested changes, while bugs were either "fix it" or "don't fix" and ordered. I've also worked with teams that sized everything - bugs and requested changes. Other teams estimated nothing, other than "small enough" or "too big". It's up to the team to find their best way of working.

Answer 2

There's no one right answer.

In fact, estimating bugs is a tricky business. What is often the case in my projects is that if we don't estimate, we assign story points for the actual effort afterwards.

This helps especially for evaluating afterwards how much % of the sprint was spent on bug fixing. This tends to help in planning future sprints (especially if the defect rate does not fluctuate too much). And on the other hand, it is a good indicator of the quality of the product, but also of the process. In Continuous Deployment environments it directly shows a correlation to the product quality. In Non-Continuous Deployment environments it is a good indication where weaknesses are in the development process. For example, if despite elaborate unit tests, mockup tests, etc., it turns out during integration that unexpected errors occur during E2E testing. In retrospectives, the focus can then be specifically directed to this.

In my current project, we already estimate the defects with storypoints before fixing them. Of course, this is more or less successful (see reasons of the questioner), but it is still better than not planning with them at all.

Well, to what extent it's economical I think also depends a bit on how much time you invest in estimating. Estimating bug fixes is more difficult than estimating user stories.

It requires more of an understanding of what has already happened in the code, and user stories are more about producing new code and embedding it into existing code. Identifying a bug as such can also take time. It may also have been a bug in the specification and you could turn it into a change request, which would then also be easier to estimate.

Bug fixes are a quest and how economical it is can therefore, in my view, depend heavily on how well the developers already know the code. I personally am not a fan of estimating bugs with story points either.

If you decide to do so, days, hours could help to have a better feeling for the sprint planning, you have to somehow plan how much time is left for other items besides the bug.

Assigning story points to a bug somehow distorts the velocity and creates a feeling of, we have given so much value. But a bug is a bug of a feature for which there were already story points and do I really want to reward a bug with an increasing velocity? So what would really be economical for me would be more finding the root causes of the bugs and fixing them. That could be too frequent personnel changes or not enough domain knowledge. Training, story swarming, better testing or pair programming could be appropriate approaches, for example.

In the teams I've worked with, bug fixing tasks are also valued. An easy bug to fix is quickly appreciated, a tricky one often not appreciated at all. That's why we work with

• lightning analyses, if our support cannot reproduce a bug. Thereby the developer invests a maximum of 30 minutes and promptly and often he sees with a few glances how severe the bug is.

• Analysis stories: Bugs that cannot be estimated in the refinement because the cause is unclear even for developers are analyzed via a storypoint-limited user story. If the bug can be fixed quickly, then this is of course done immediately. If the analysis or the bug fix requires more time than the agreed (1, 2?) story points () then the story is aborted and the intermediate result is communicated. The Story Points are defined once as a rule of thumb. For us 2

.

Answer 3

In my experience, this can be a controversial question.

I've worked on teams where devs said to not point bugs for the very reasons the OP is posing: too difficult. I personally don't buy the "bugs are more difficult" or "takes too long to investigate" to point than other types of work. To me, all types of work should have an estimate attached to it.

I've also seen teams that said the points a bug has should have been included in the original feature work. As in, if the feature was a 3 point ticket and a bug is found and it's a 2 point bug to fix it, then the original ticket should have been 5 points. I don't agree with this argument either as bugs and features aren't zero-sum.

Another argument is "a bug estimate will never be accurate and we should be as accurate as possible in estimates." The counter here is feature estimates aren't accurate either, but the difference tends to be in planning: feature work gets the time to to question, get answers/clarifications, able to scope down if seen as too much or too complex.

The idea of not pointing bugs really comes down to whose work is seen as more valuable. To devs and others, it's the dev work and QA work is seen as "less than."

Oftentimes the "difficulty" or the "time" arguments come down to the bug reported doesn't have enough details to support an accurate estimate.

In the case of bugs, how can you go about ensuring they are seen as valuable to fix and easier for the team to estimate?

• Ensure all bugs are using a bug template and the entire team is using said template. This allows you to capture all the pertinent information about a bug.
• Ask the developer that knows most about the feature where the bug is occurring to come up with an estimate. They'd have the most detailed knowledge of the code to provide a good estimate.
• Triage bugs in a separate meeting with testers, devs, and product managers in attendance. If not a separate meeting, ensure bugs are triaged in a planning meeting. Here, the team can ask questions, get clarification on the bug, see a demo of the bug the same way they would in estimating a feature.
• Ask the team for suggestions on how they can estimate bugs easier? What are their objections, concerns, or even roadblocks

I'm sure there are more ways; these are the ways I've used and implemented on different teams. The idea is to treat all work as equal and to give equal opportunity to gain knowledge about the work before estimating it.

I'm a big proponent of using bug templates. I've worked with teams that didn't use them at first and they had all the above arguments and more. Once they started using the template, they found it was easier to understand the issue and measurably faster to fix the issues.

Answer 4

Whatever your team has agreed upon is the answer. Some teams won't consider a user story done if there are open bugs, so they are "baked-in" and do not get additional points. On the other hand, if you found a legacy bug and it is a business priority to fix, then it may or may not be assigned points. It is difficult to estimate points for bugs since the developer won't know the required effort until they start debugging it.

Answer 5

From my experience, we always give point to bugs ,but bugs does not take as much as point as a story , so sometimes we combine 2-3 bugs also when they are minor, but story point must be given.

Answer 6

Yes - That is what we do because developer and team do have to apply their effort in order to investigate, debug and resolve them.