Ideally, your software should be bug-free after each iteration, and fixing bugs should be part of each sprint, so the work required to fix bugs should be considered when assigning story points (i.e., a task that is more likely to produce bugs should have more story points assigned to it).

In reality, however, bugs surface post-deployment all the time, no matter how rigid your testing; when that happens, removing the bug is just another change, a feature if you will. There is no fundamental difference between a bug report and a feature request in this context: in both cases, the application shows a certain behavior, and the user (or some other stakeholder) would like to see it changed.

From a business perspective, bugfixes and features are also the same, really: either you do it (scenario B), or you don’t (scenario A); both scenarios have costs and benefits attached, and a decent business person will just weigh them up and go with whatever earns them more profit (long-term or short-term depending on business strategy).

So yes, by all means, assign story points to bugs. How else are you going to prioritize bugs vs. features, and bugs against bugs? You need some measure of development effort for both, and it better be comparable.

The biggest problem with this is that bugfixes are often harder to estimate: 90% or more of the actual effort lies in finding the cause; once you have found it, you can come up with an accurate estimate, but it is almost impossible to judge how long the search will take. I’ve even seen a fair share of bugs where most of the time was spent just trying to reproduce the bug. On the other hand, depending on the nature of the bug, it is often possible to narrow down the search with some minimal research before making an estimate.

You should not give points to bug resolution. Consider the fact that the bug comes forth from a story where the developers already earned points for completing the story. It should not receive points again where it actually shouldn’t have earned the points to begin with.

Bug fixing should have a negative effect on velocity. Otherwise dropping quality ends up being rewarded with an unaffected or even increased velocity!

Perhaps a useful link:

http://www.infoq.com/news/2011/01/story-points-to-bugs

Estimating bugs with points is inherently difficult as already pointed out in other answers and yes the ideal solution is that bugs found in a feature AFTER the sprint has been accepted should be considered new features.

This difficulty in point estimation for bugs however is one of many reasons that Agile PM software packages allow for tasks and bugs to be estimated in hours, because it takes dilligence and experience to become skilled at point estimation. Many projects run into significant problems with properly determining velocity, so many Agile projects use points to determine what stories make it into the sprint, however they use hours when calculating the burndown chart.

It seems counter intuitive but manageable as long as hours estimation is not used as a factor in determining the sprint commitment. Overcommittment will naturally lead to missed or incomplete features or overtime, so over time all involved are forced to get better at point estimation, at which point estimating hours on tasks and bugs slowly become a meaningless metric.

I would recommend treating the bug as a user story and assigning it a number of points. I wouldn’t necessarily write it in the format of “As a X, I want to Y so that Z” as is common with user stories – I’d write it more as “As a X, when I Y, Z happens, but Z’ is the expected behavior”.

The advantage of this is that it allows you to prioritize bug fixes right along side new feature requests. The truth is that sometimes, a new feature is more important than fixing a bug. However, it also allows you to properly size the work required, allowing you to fit it into a sprint when you have the capability of doing so.

One thing to keep in mind that it might be difficult to estimate the effort that is required to fix a bug. It could involve multiple components that interact with each other, requiring someone to become very familiar with the interactions of large pieces of the system or multiple people to work on the fix.

Estimating stories is based on the notion that, with time, a team earns experience in resolving them. With it accuracy is improved and velocity can be established to measure a teams speed. A perfect methodology for establishing reliable prognoses for future sprints.

Bugs are a fact of life for a software development company. While I agree that bugs should all be caught during the development of a story, accepting that this cannot be achieved at all times, should be something that every team should plan for. Instead of stubbornly thinking that the process should rule the team, it should be the other way round.

Of course, bug or story, from the business side it does not matter what the team is dealing with. Both can produce an equal amount of value for the product owner.

In our team we have experimented with some techniques for estimating bugs:

1. Estimating completely unknown bugs
2. Only estimating bugs which were already analyzed
3. Allotting time for bug fixing and not estimating bugs, but rank them instead solely based on business value

With 1. we have failed misearably. For most bugs we have found 90% of the time is spent on the bug analysis. After that the bug fix can be estimated in the same way as a story. By planning the bugs into a sprint we made the mistake that the unknown scope impacted story resolution up until the point where almost every sprint we did this way failed.

Based on the 90/10 ratio (analysis to bug fixing) estimation technique option 2. did mean that we had to plan for analysis which was not something that was covered for sprint planning (we had learned from option 1, but had no real solution how to go on with analyzed bugs). The result was that bug analysis was not done since a sprint focused on the planned items instead. The team did not have time to focus on bugs from the backlog. So eventually they did not get done either.

By embracing uncertainty we have now settled on option 3. We have split up the product backlog into a regular story/task part that can be estimated by the team using story points and a bug backlog. In the bug backlog the product owner ranks bugs based on business value and very rough team judgement. The team allows for allotting a chunk of time during a sprint that it can spend on focusing on bugs. The product owner does not know the exact outcome as it was not possible to plan that anyway before. The ratio of bug backlog versus regular backlog can be adjusted for each sprint depending on the current status of each backlog and the importance and business value of the content.

By taking out the uncertainty it did free up the team again. Sprints were not compromised by unknown bugs. By separating bugs into a different backlog both increased team’s regular sprint focus and made us finish bugs which contained significant business value as well.

So it depends whether story points are suitable for you. I would try to estimate bugs using story points first. If that fails try my option 3. It has made our (over 30 sprint old) team focus on older bugs again which contain great business value. It has also freed us from trying to deliver something which the team simply cannot estimate. It was embracing the unknown that got us closer to the reality and also made our sprints successful again while delivering a big chunk (based on the bug to story ratio) of business value through bug fixes. The ratio we used recently was 50/50.

I have to disagree with the top answer of assigning story points to bugs. Story points should be for new value being delivered. If you are going to assign points to product value and non-value items, you might as well just estimate and track hours.

Bugs are the overhead of what you did yesterday and is not indicative of the velocity of product completion, and they don’t create any new product value either (think about it). Bugs are kind of like interrupts and all the other cow pies you need to deal with on a weekly basis. The whole idea of story points is that it tracks/estimates when we will deliver the product (or feature set). Story points are arbitrary and that’s how it removes all the non-value overhead from estimation. Generally the non-value work is constant week-to-week, so it is built into the team velocity. The team will accelerate when they remove or reduce this non-value work.

Put another way, why even track points to bugs? So that at the end of the day you know how much “work” each member did? Stop that! Bad manager! 🙂 Measure the team, not the player. Encourage the team to manage themselves if one person is not pulling their weight. Much more effective. Doing story point items should not make an individual feel better, but the team as a whole should feel better when they make their commitment at the end of the sprint. In sports, is the goal good for the team or the individual? If the individual plays for himself the team loses in the long run.

You know, eventually you want not to use points at all. Estimation is time taken away from real work. When a team reaches maximum chi they don’t use points at all yet know exactly how many items they can pull into a sprint. They’ve mastered the art of breaking up units of work that estimation is process waste.

Some tasks are estimateable, some are not. For things that cannot be estimated, use a budget.

Fixing a defect is not a readily estimateable task because it has several unknown components to it. What is causing the defect? Once the cause is understood, how can it be fixed? What impact does this change have on the rest of the system? How many new defects did you inject fixing this defect?

Keep in mind that the cause of a defect can come from any point in the software lifecycle — misunderstood or miscommunicated requirements, poor design or wrong assumptions, poor coding, bad testing, new knowledge about the problem based on information learned from the current release…

Creating a budget can be done in a couple of different ways for bug fixing tasks. Here’s some ideas I’ve used effectively:

• Use historical data (say from a previous iteration) to help you understand how much time to set aside for bug fixing.
• Put “blocks” of bugfixing (say 5 points or 20 hours) in your backlog and let the customer choose this in lieu of stories.
• Require that each member of your team dedicate a specified amount of time each iteration fixing defects.

Your goal is then to fix as many defects as possible within the budget allocated. Discuss with your customer strategies for prioritizing reported defects. For example, do you sort defects by criticality then priority? Strict priority? Should you attack “low-hanging fruit” first? UI bugs first?

Also, fixing bugs does not earn value. Fixing defects are a form of waste. You already earned value on the feature so you should not get “bonus points” for fixing bugs.

Having a budget helps with planning and still gives you an accurate picture of Velocity. Budget a specific number of points for bug fixing, give the budget an approximate amount of time based on your historic data, and then squash as many bugs as you can in the time budgeted!

Instead of the focus on stories and bugs and chores and the points each has, I find it better to focus on delivering features for the customer.

Customers expect the software to work and only give real value to development, enhancements and new features as these drive the business forward.

Bug fixes, as important as they may be, do not drive the business forward into new areas and new customers (tangentially and eventually perhaps yes but not immediately which is what management is measuring).

So points are best viewed from the higher viewpoint of velocity and how many points per week have been done historically for similarly scored stories.

This can lead to a management by track record history rather than pushing the urgent need for this weeks stories to be complete and frequently finding that they are not. However the loss of up-front control and increased trust that this requires will have some managers running for the door in horror.

I use Pivotal Tracker (I’ve just JIRA, Trak, Trello and others too) and Pivotal Tracker also does not do points for chores or bugs. It’s done for the same good reasons above that make it also true in JIRA as you are seeing yourself.