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

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.

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?

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

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?

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.

Thanks everyone, specially Daniel Wilhite and Steve Matthew!

Your comments really helped me. :)

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

Cons:

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!

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.