Estimation in Story points for bugs?

Last post 08:55 am September 6, 2019
by Anahit Marutyan
6 replies
Author
Messages
01:17 pm August 26, 2019

Is it ok to estimate bugs that are not related to a specific User Story or Improvement in story points. Or in other words how the bugs not related to US (or related to previously closed US) should be estimated? And should they be included in final Velocity Calculation?

02:17 pm August 26, 2019

All remaining work should be accounted for on the Product Backlog. If it is being actioned in the current Sprint, it will be accounted for on the Sprint Backlog.

It should be possible to sum the total amount of work that is thought to remain on a backlog. Why would you estimate bugs differently to other backlog items?

10:58 pm August 26, 2019

I've seen two approaches to this:

  1. All bugs are either small ("that's an easy thing to fix, I know what the issue is") or unknown ("I don't know why that's happening, I need to look into it"). So estimating bugs is not as valuable.
  2. Bugs are another way to represent work that needs to be done on the product, so they can be estimated.

What does your team think?

01:37 pm August 27, 2019

Anahit,

Defect-related items in the backlog usually represent a much larger "unknown" than other backlog items, due to the need for investigation, research, trial and error, etc.   Basically, we don't know why something doesn't work as expected.

In my opinion, the team should still provide an estimate around the complexity and effort they feel is required to resolve the defect, for reasons stated above.   How else can the team gauge whether they can forecast completing the defect item in the sprint, if they cannot agree on a rough size for it?   Otherwise, it's just a big black box that the team is being asked to work on.

It may be a large estimate to account for unknowns, but that is fine - hopefully, the team will improve how they estimate defects the more they practice it.

And always keep in mind that these are estimates, and the Daily Scrum is a perfect opportunity for the team to assess progress on it and consider whether they are on track with their original sizing or not.

03:13 pm August 27, 2019

I usually coach that there is no such thing as a bug in the Product Backlog.  When you have multiple item types it is human nature to try and deal with them differently.  I have heard "Oh that is just a task, we don't need to point it" and then it turns out to take 3 days to complete the task while they completed 2 stories in the same 3 days. The fact that you asked this question shows the desire to handle the items differently.  

I recommend that there be nothing but stories in the Product Backlog.  Everything is treated equally.  There is value to fixing bugs just as there is value to delivering an enhancement.  There is also negative value to not doing the work for both.  Treat them all equally. 

03:49 pm August 27, 2019

There are lots of opinions on this - just see the earlier replies.

Personally, I favor estimating bugs. Once any work hits the Product Backlog, it needs to be estimated, however your team estimates. Now, there may be insufficient information to reasonably estimate it, but this is what Product Backlog Refinement is for. Once there's a good understanding and scope around the issue, it can be estimated and the Product Owner can order it. If you're tracking velocity, then everything that you deliver counts toward your velocity.

08:55 am September 6, 2019

Thank you for your replies, actually I am totally for estimating the bugs the same was as US, I just want to double check to start applying SP estimation for the team for the first time ))).