Estimation in Story points for bugs?
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?
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:
- 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.
- 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?
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.