Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm just wondering if we should assign story points to bug fixing tasks or not. JIRA, our issues-tracking software, does not have story point field for Bug type issues (it's only for Storys and Epics).

Should we add the Bug issue type to the applicable issue types of the Story Points field? What are the pros and cons? Would it be suitable for Scrum?

share|improve this question

7 Answers 7

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.

share|improve this answer
    
I was in the middle of writing an answer that ended up being nearly identical to yours. I like your explanation better. –  maple_shaft Aug 24 '12 at 11:43
3  
The only problem I have is your fourth passage. You don't prioritize based on story points (at least, I've never seen that, and it seems rather silly). You prioritize based on business value added and use story points to determine how many of the stories you can complete in your timeboxed iteration. It's entirely possible to take a less prioritized story into an earlier iteration because the ones above it are too large to fit within the projected velocity. –  Thomas Owens Aug 24 '12 at 11:53
2  
@ThomasOwens: OK, let me rephrase that. What I meant is that story points are required to judge the benefit of any change vs. its development effort. Of course the benefit is just as important in prioritizing as the effort. –  tdammers Aug 24 '12 at 13:47
    
I like the general notion of your answer. We have solved the prioritization/ranking issue by separating bugs into a separate backlog and creating a ratio (regular backlog to bug backlog) to deal with what you are describing in the last two paragraphs. Your last paragraph describes the problem inherent to bug fixing quite well. And it is also the reason why we are not doing story point estimation for bugs. I have expanded on why your solution approach failed for us in my answer and how we got out of it. –  malte Aug 27 '12 at 5:23

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.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer
1  
I understand your arguments about creating a positive environment for developers to write buggy code and having meaningless velocity, but keep in mind that bugs found in a feature after the sprint has been accepted means that the testers made a mistake in not catching these bugs before acceptance. Furthermore completing user stories should not be a race to begin with, if a developer is completing many more user stories in a sprint than scheduled, that means he is not estimating the story effort in points very well. With that metric, developers look good just by over-estimating all the time. –  maple_shaft Aug 24 '12 at 13:19
2  
The velocity (measured in story points per sprint) measures how much stuff the team can implement in a sprint. I'm sure every product owner keeps track of, and is much more interested in, how much business value the team produces. Business value doesn't get inflated from giving bug fixes story points. –  Buhb Aug 24 '12 at 13:28
1  
@buhb story points say nothing about business value. A 5 point story could have 100 business value. A 100 point story could have 1 business value. It expresses effort not business value. –  Joppe Aug 24 '12 at 13:31
1  
@Tungano: Exactly. That's why assigning points to bug fixes doesn't give a strong incentive to build buggy software. –  Buhb Aug 24 '12 at 13:35
2  
The inflated velocity from including bug fixes causes another problem: it destroys your ability to use velocity to project into the future. Velocity should be a measure of how quickly the team can accomplish the work they set out to do, not a measure of how much work it actually was. –  Chris Pitman Aug 27 '12 at 2:14

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.

share|improve this answer

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.

share|improve this answer

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!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.