Estimation in Story points for bugs?

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?

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?

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.

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. 

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.

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 ))).

Hey guys, here is my 2 cents...

In our team, and in some of my past teams we never rated the bugs, neither planned deployments or other non product valuable tasks.

Our team velocity is growing over sprints since there less bugs as product knowledge grows and since there is more and more automation in tests and deployments.

That said, the team was taking in consideration the time needed to execute these non product valuable task though.

Here are my two cents...

If at the end of the sprint, everything is already passed according to the definition-of-done, then theoretically there will be no bugs. Otherwise this would not be considered as a done increment, and thrown back to the product backlog.

If it already passed the definition-of-done and bugs are found later, then perhaps it's a minor one (otherwise you need to take a hard look on your definition-of-done).  And if that bug-fix still make a way to the product backlog again, I personally prefer to have an estimate on it.

Recently I was challenging if we should estimate Bugs with Story Points in my team, and I have mixed feelings about it.

While I agree that fixing bugs takes time and the effort might not be small, we should not forget that story points is a relative unit of measure. If you want to measure also time, then you should measure the amount of time a story or bug TOOK to be done, i.e. AFTER it was done.

If we estimate bugs with story points, how am I suppose to look at our sprint burndown chart (or release burndown chart) and understand where we stand? What if our bugs have more story points than our stories in these charts?

On the other hand, if we don't estimate bugs, but we do get many bugs and spend a lot of time fixing them in detriment of implementing stories, then this will be easily detectable in our team's Velocity.

This being said, I agree more to categorize bugs as user stories from the start, than estimating bugs (in case we use this categorization) with story points.

Let's assume a sprint in which only Bugs are resolved, corresponding to features released in the previous sprints. How productive is the team in that sprint? I'd say Zero.

If some bugs are actually new requirements, I would try to express them in the form of User Stories. But if they are Bugs, the team's velocity is 0. Therefore, it makes no sense, in my opinion, to assign story points to Bugs (they require time, but do not contribute to the team's velocity). A 0 speed sprint is a call to action that we have to take enough time to develop and test things: to try to keep bugs to a minimum.

Let's assume a sprint in which only Bugs are resolved, corresponding to features released in the previous sprints. How productive is the team in that sprint? I'd say Zero.

Velocity is the rate at which work is Done. It's the velocity of the previous Sprints, therefore, that is more likely to have been zero. The velocity of the Sprint within which these "bugs" have been fixed, on the other hand, stands to be non-zero -- since work has now been Done -- and thus greater than before.

it makes no sense, in my opinion, to assign story points to Bugs (they require time, but do not contribute to the team's velocity)

The purpose of estimation in Scrum is for Developers to get their arms around how much work they can take on in a Sprint. Everything else reduces to value and empirical process control. Any defects they take on in a Sprint should therefore figure in their estimates.

It's the work which isn't Done that fails to contribute to velocity.

Velocity based upon Story Points doesn't help a team fully understand how much work they can do in a Sprint.  Story Points are an estimate(i.e. guess) made at a point in time based upon the knowledge that exists at that point in time.  As soon as work begins, the estimate is no longer relevant because you will gain new knowledge.  That is why something estimated as a 5 could take longer to complete than something estimated as an 8.  

As @Ian said, velocity is the rate at which work is completed or done.  To measure that you would be better served to look at flow metrics like throughput or cycle time.  To measure if work is done, you use your Definition of Done. The purpose of a Sprint is not to complete a lot of items, it is to achieve the Sprint Goal.  The Sprint Goal defines the purpose of the Sprint and the value that is hoped to be achieved.  

So, for a Sprint where only bugs are worked on, the velocity would the time it takes to achieve the Sprint Goal.  The value delivered is defined by Sprint Goal. 

I'm also going to comment on the need for bugs vs stories.  The Product Backlog represents all work needed to improve a product.  New features improve the product.  Fixing defects improves the product.  So why do you distinguish between the two? By making them two different entities, human nature is to treat them differently.  That is why you have the struggle about pointing bugs.  Create one item type and handle every item the same.  Then there is no confusion.  Each item represents value that will be delivered. 

Let's assume a sprint in which only Bugs are resolved, corresponding to features released in the previous sprints. How productive is the team in that sprint? I'd say Zero.

Your team has just fixed a lot of bugs -- probably increasing customer satisfaction by improving the quality of your software. As a result, your team will be able to inspect a higher quality increment at sprint review.

If a task is taken to the Sprint it should be estimated no matter if it's a bug or a user story. This is a robust and consistent approach. And if they are estimated they will be included in the final Velocity Calculation. In my experience, the only difference between bugs and user stories in the context of the Sprint is that bugs are not as often demo-able as user stories.

You can’t estimate defect until you complete triage and identify root cause. So, doing it before that, you will get wrong data and all your future planning will be inconsistent.

Story points is relative estimation. I don’t think we can compare story and defect.

Now, If we would estimate defects, then velocity would represent an effort (then - we may also estimate time we spend in a ceremonies and etc) Meaning, the velocity will be flat or inconsistent because of my first comment.

Velocity represent team speed to introduce new functionality/value (how quickly we can delivery value to the customer). Defect resolution is also value but defect represent unexpected behaviour (something was suppose to work and doesn’t work now). If team spend more time of fixing defects, velocity will go done. This will trigger the conversation about quality or other improvements. Velocity is very simple but powerful metrics for the teams.

Also, velocity is the tool to forecast when new functionality can be delivered. If it will include defect resolution effort, the forecast (size of new functionality * velocity) will show you incorrect predication because it includes defect resolution and you will have hard time to justify that you need more time because of potential defects (nobody write 100% bug free code).

I would not recommend to estimate defects. Fix them as quick as you can.

Hi Alex, 

If you read through the Scrum Guide, you will see no mention of stories, or bugs. You will see the Product Backlog as an emergent, ordered list of what is needed to improve the product, with Product Backlog items representing the elements in that list of what is needed.

If defects (or technical debt, or technical tasks or whatever) enter the Product Backlog, they are included in the list of what is needed. They become Product Backlog items and ought to be treated the same. This supports consistent transparency for Backlog items, which is important when you inspect and adapt during various Events.

If flaws (defects) present themselves during a Sprint as part of a Product Backlog item meeting the Definition of Done, then I would agree. No need to size the correction of these flaws as this is part of the work associated to the Product Backlog item being worked on. 

To borrow Scrum.org's definition of Velocity...

Velocity: an optional, but often used, indication of the amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Developers for use within the Scrum Team.

Velocity is simply an indication of the amount of Backlog that could be turned into an Increment for a Sprint period. I would decouple velocity from forecast, or predictions as it isn't a "when" measure. Agree that velocity is a simple measure, but in my experience, it can be dangerous and misleading if used for anything beyond the above definition. One example is how it may influence how a team treats their product backlog items differently as not to disrupt their use of velocity.

This is a really old thread but I'd add one thing which is more of a customer management point of view that clearly shows its face at the product management scene as well: In my experience most bugs arrive to the Product Backlog as the Customer describes them. Usually it has a severity flag that could be based on a lot of thing. Like "is it a dangerous mistake? (life critical application)", halting Customers' business, "anger level" and "how important this Customer is to us (loosing market)", etc. 

I think the above reason is why "bug" as a Product Backlog Item type still exists and why people feel the urge to treat these items differently. This could be the reason for "expedite/fast lanes" as well. In panic, the 1st thing people do is forgetting why they're using Scrum and they try to manage problems "the old ways", adding additional complexity, etc.

With this post I just wanted to support the others' explanation on why shouldn't we handle these items differently.