How bug prioritization works in agile projects vs non agile

Question

When reporting a defect, we are setting the priority and severity of the defect. How this works with agile development? Is there any specific way ?

How bug prioritization works in agile projects vs non agile.?

Is there any other way of measuring the priority of a bug in agile projects?

Answer 1

A generic answer is: It's contextual; the team and stakeholders (which is who understand better the context) should work towards finding a good way - and periodically analysis its efficacy and improve on it.

However, I see three major approaches. E.g.:

1 - The team defines strict rules for labels:

• High: The user cannot use some feature
• Medium: The user can perform the actions using some workaround

• Low: An error that basically does not affect usage (such as a small typo)

  It can be agreed that all High will be tackle in-sprint and every X sprint there will be time for Medium and/or Low.

2 - Stakeholders review all bugs and decide which and when to tackle each bug.

3 - Zero Bug Policy:

A Zero Bug Policy is simple. All bugs take priority over all new feature development or improvements. That’s it. There is nothing more.

An important corollary of this approach is that there is no such thing as bug priority, critical bugs, or minor bugs. An issue is either a bug or it isn’t. And if it is a bug, you need to fix it before doing other work.

Answer 2

In more traditional software development cycles, defects are found during a testing phase and in production by users. Defects would be logged in a defect tracker. Depending on the severity of the defects, it could block a release or users and might need fixing asap.

In more Agile software development cycles, defects found during an iteration (Sprint) are fixed during the iteration, if they are a result of changes during the iteration. Production defects would be put on a backlog and prioritized by a business representative (Product Owner). I always advise on using a zero-defect policy, as you don't want to iterate on quicksand and sink deeper and deeper into a brittle application.

Nor Agile, nor traditional software development cycles define how you need to handle defects. Technically you could have the same process for both. But in Agile postponing fixing defects might give the team an unfair feeling of how fast they are going. Defects are part of items (User stories) delivered in the past. If your planning is based on the number of items you process you should always prioritize any defects high to keep your velocity real.

Answer 3

Same as non-agile.

Record the bug, set priority and severity.

Maybe you are asking about what happens next in agile vs. non-agile?

That depends. The main differences with Agile might be

• Instead of filing a bug the developer fixes it immediately (like within a day say)
• Enter bug but instead of the bug taking weeks or months to be worked on it is worked on immediately
• Instead of entering bugs and adding bugs to the backlog they are entered and added to current work
• Bugs are worked on before new features

These are not defining characteristics of agile and many of them might be done in non-agile shops with quality approaches. But these ones might be different in some places.

So maybe the question is 'how are bugs handled differently in Agile development?"

Answer 4

Looking backwards to Non-Agile projects it had a few problems:

1. Eveything that didn't fulfill the specification is a bug. You had a contract, you wrote an specification. You had to fix it. Of course there were room for ambiguity, discussion and interpretation. Negociating power was important and contractual penalties for not reaching dates were really crucial.
2. The specification wasn't perfect so there were small contradictions or holes that the developers had to solve. Some companies even forbidden asking the client's domain experts. In any case you ended with bugs that acording to the specification were features.
3. In most case you needed to continue the analysis during the project updating the specification was with the result of endless meetings and emails. There were some expensive tools to trace this changes.
4. Some of those bugs were so blatantly problematic that needed to be solved for comercial reasons even if were OK acording to the specification. Some features were so needed once that the product worked that extensions to the contract were negociated.
5. Time is limited so bugs and features were priorized usually with some help from the client anyway. Some clients were helpful. Some just said thet everything was important. On some projects QAs or managers set the priorities.
6. In the best case you could always exchange leaving some low priority bugs for some new features.
7. Sometimes there where "guaranty periods". Anything that wasn't found in X months wasn't a bug. Clients had incentives to find every small bug or disguise changes or features as bugs. A lot of time of the development team would be spent fixing this "guaranty" bugs that could have been used to create new features.

In agile:

1. The level of quality depends on the client. They set their preferences between new features and polishing the old ones. Priorities may and will change between sprints.
2. Cost / time to develop is always evaluated by the development team. Priority is set by the client. It doesn't mind if it is a bug, change or new feature so we can avoid this discussion.
3. You do not need a lot of very complex list of bug tracking. It is better to have a subset of candidates tasks ready for the next sprint. This mean that they are well understood and its cost is evaluated so that the client can decide.
4. We sometimes learn new things a about the problem that change everthing. Test cases need to be updated and the concept of bug changes. And code is already in production so the priorities are usually more customer-centric.
5. Some bugs may be technical debt affecting the develpment team. They may find in their retrospective that the way to improve the velocity is just to fix the bug. They will fix it as it is the optimal way to produce more value.
6. Even if you are agile common sense should be applied: if you are in a bank and a bug can make you loose 100.000.000 dollars you stop to fix it. If it is against the law and you are in production you fix it. If you are modifying a class and you can solve something with almost zero effor you solve it.