Ttyjukl

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?

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: Some feature is impossible to the done by the user


• Medium: The user can perform the action using some workaround


• 
  

  Low: An error that basically do 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 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.

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?"

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.