Skip to main content

Is it standard process to take story points in the bug also?

Last post 02:23 pm December 24, 2022 by Luat Dinh Gia
8 replies
11:40 am July 15, 2020

I think, we had already taken story points(while implementing any feature) then why to take point in the bug found against that feature already implemented.

So as per Agile, is to standard process to take story points in the bug?

I would like everyone to give some thoughts on this topic.


03:52 pm July 15, 2020

So as per Agile, is to standard process to take story points in the bug?

@Rajat Kumar, There is nothing in Agile or Scrum that says you have to use story points.

Now, when you say bug, are you talking about a Product Backlog Item not meeting the Acceptance Criteria or the Definition of Done during the Sprint? If yes, then there is no need to estimate because the PBI hasn't met the DoD in the first place.

If what you call a bug is a defect, for example in Production, then yes, estimating the work would help you plan for the next Sprint.


05:45 pm July 15, 2020

So as per Agile, is to standard process to take story points in the bug?

How important is it for a team to keep track of how much work they think genuinely remains?

07:54 pm July 15, 2020

When you guess at the complexity of satisfying the problem statement contained in a Product Backlog item (or in other terms put story points on a User Story), any skilled and professional software professional would leave a level of uncertainty in their estimate to account for things that will be discovered while working.  So if someone discovers a defect in the code that should be accounted for in the estimate to complete the work and no further estimation is needed.  This covers the discovery of a defect while testing code changes made during a Sprint.  (I actually go further and suggest that no one actually creates a defect in our tracking system because keeping track of changes made during the creation of a code is done by the source code management system.  Just comment on the code check-in that they are fixing an issue found with <blah> <blah>)

If an issue is found in Production it should be documented and placed as an item in the Product Backlog.  Scrum Guide states this in the section describing the Product Backlog:

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when "Done".

So when the description of the defect is captured as an item in the Product Backlog, it should have estimation as one of its attributes.  (Again, I go even further and say that you should not distinguish between bugs, stories in the Product Backlog.  Create them all as a single item type and treat them equally.)

01:49 pm July 16, 2020

Thanks All :)

Let me be more precise on my query:

Suppose we have many stories as a part of implementation work in any specific feature. We given estimation and story points in the sprint work for all those work.

Now, at the time of Release or Acceptance phase, we got some bug/defect by the tester/client in the same feature we already implemented

Question:  Should we take story point for that bug/defect found(from already accepted/released feature) and kept in Product backlog to get them fixed in any sprint or just estimation will be given for that work?

My Opinion: We shouldn't get story points for a bug to fix a feature for which we already received story points for.

Thoughts please?

04:33 pm July 16, 2020

Now, at the time of Release or Acceptance phase, we got some bug/defect by the tester/client in the same feature we already implemented

Could you elaborate what you mean by release or acceptance phase? Why do you have phases? Is this happening during a Sprint? If it was not during a Sprint, did it really meet the Definition of Done?

We shouldn't get story points for a bug to fix a feature for which we already received story points for.

As I previously said, Agile, or Scrum does not require the use of story points. Why does "receiving" points matter so much? I hope you understand that the only purpose of using the story points technique is for planning. Beyond that, there is absolutely no value.

Since you also mention that this defect is something that was caught once released to production, therefore, it become a PBI in the Product Backlog. So, long story short, yes, it has to be estimated and consequently be assigned story points.

02:34 pm August 25, 2020

Thanks everyone, specially Daniel Wilhite and Steve Matthew!

Your comments really helped me. :)

12:00 pm August 28, 2020

My two cents here.

If you found a defect or issues after deploying a feature, you can / cannot estimate that new PBI using Story Points;

Pro to use story points:

You have some degrees or estimation on how long the team believe will be required to fix the issue


Because is a bug, something missing in the requirements or a behaviour unexpected in production, I found that teams are struggling to provide a useful estimation in terms of Story Points, to the bug, especially if there was no root cause analysis activity started.

My personal suggestion is to listen to the team and how they will react to not story points bugs or story points them after an initial analysis that can help the team to have a fruitful conversation during the grooming sesssion.

Majority of teams I'm working on, are not story pointing bugs or, when proposed to remove Story Points estimation from bug, they were happy to experimented and accepted this new way (our caveat is that we should have restricted number of bugs to work per sprint, and developers working on bugs should rotate).

Thank you!









08:18 am December 24, 2022

In my opinions:

1/ Bugs found during Sprint is a part of Stories team've already given the estimation. Basically, these Bugs and related Stories have a same purpose is to serve the current Sprint Goal, so it's very clearly that the estimation for these Bugs are not need in that time.

2/ In some way the Bug is found and not related to Sprint Scope/Goal. This should be treated equally with other Backlog Items and need to be estimated by Story Point.

3/ And of course, always listen to your team and get their agreement to ensure the transparency.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.