How to manage bugs which open during active sprint w/o impact burndown

[Ofira Daniel]

Hi All ,

During sprint we know that bugs (which not related to user stories which being handled in sprint) will arraive (can arraive from field , application work , general regression version that was found and more).

Our grooming set effort in story points and scrum team set their effort in hours on their sub tasks.

In order to keep burdown w/ jumping the following is being done :

1. Open user story - time box for all bugs that will be opened and set story point value 
2. Open below the time box user story sub task with hours allocation which saved for it .
3. During sprint for each bug which opened - we opened bug we allocate story point & create sub task/s and allocate hours and remove it from the time box user story / sub tasks which kept for bugs 

This is not intuitive and not confort .

Please share how you manage it 

Thanks ! 

[Maarten Cautreels]

Hi Ofire,

At De Persgroep, where I work, we tend to apply a Bugs-first-policy.

This means that, once a bug is found/reported, we'll pick it up once we finish with our current work.

Why?

• Nobody gets happy about bugs
• Once they get found, the code/implementation usually is still fresh in our mind, thus taking us less context switching to get back in there and fix it.
• Bugs usually are small/not that much work and we want to avoid them hanging around in our backlog for too long
• We don't estimate bugs. They usually are hard to estimate and we already earned the story points for this particular feature. We just made a mistake or forgot something. So why would we earn any points for making a mistake?

By not estimating bugs, you get rid of the issue that they have visual impact on your burn down.

Off course they do have impact on the amount of real work the team can do and depending on the number of bugs, it could be that the team will not finish all work they committed.

So in short: don't estimate bugs (not in story points or in time).

Hope this helps.

Best,

Maarten

[Ofira Daniel]

Thanks ,

Interesting approach , need to think on it . 

Problem is that we are talking also on bugs from old development (even 1 year back) that we didn`t find before.

Plus in this approach by looking on Epic total effort , I won`t really know the real effort , as all bugs I found post story completion won`t get story points.

Still understand your approach that no one need to get price for mistakes 

[Maarten Cautreels]

Hi Ofira,

We do have teams in a similar situation. Some even have applications that are 5 years or older.

Our agile coaches have drawn the following diagram which should help you identify the bugs that you don't want to fix or maybe want to fix as an improvement instead (which you do estimate):

Apart from that you can try and convince your stakeholders (and PO) to do a bug-only sprint to get rid of these legacy bugs and clean your backlog.

About the epics and total effort, are you looking at time spent or story points?

• Time spent: the team can still log time on bugs, that's no problem.
• Story points: the story points estimated on the stories should have included the work on the bug as a bug usually is a requirement of a story not being met. 

Best,

Maarten

[Ofira Daniel]

thanks .

Regard your question , we look on both (Depend who is looking..)

[Gerben Blom]

Hi Daniel,

We have a different and slightly mixed approach. For priority issues we have a separate Kanban board. Those issues need not be estimated and have priority over the Scrum backlog.

Issues that can wait are estimated and put in the regular backlog.

Of course the amount of priority issues has a negative effect on the velocity. The problem in our case is that the load of priority issues is not equally divided over the year. We try to take that into account by planning for a lower velocity during the busy parts of the year.

To give a proper insight for the team we made our own board (via the Jira API) that shows the priority issues in the top swimlane, and the sprint items in the rest of the screen.

For us this works quite well, it might be useful for you too. 

[Patricio Rivera]

We have been facing the same question. Although I don't have a solution I think I can share some of the improvements we've made.

First of all, we have three bug categories:

1. Bugs with medium or low priority: This issues are created into the Product Backlog and will be resolved as any user story depending on business value.
2. Bugs with high priority: This errors are created and moved to the Sprint Backlog instantly and are deployed in the sprint increment after the sprint review.
3. Hotfixes: These bugs causes serious problems on business operations and can't wait to the next scheduled deployment. This bugs are created and moved instantly to the Sprint Backlog, but they are also deployed immediately when they are done (programmed and properly tested).

Maarten diagram it's great. I'll share it with my team. But I think we should use always issues' business value to take the final decision. Of course impact and time to resolve are important component of business value.

If we resolve issues by business value, some bugs can live for a long time on the Product Backlog. Some stories have more value than certain bugs.

Just being a bug is not enough argument to be at the top of the pending work.

It's nice to read what you are doing. I'll share and discuss some of your practices with my team too.

[Maarten Cautreels]

@Patricio Rivera Completely agree that value should always be thought of. But we have this "Bugs-first" guideline simply because a bug is a particular feature (which was previously agreed on it had value) which isn't working as intended, thus the value (as previously agreed) is not being delivered.

That's why we think most bugs should be picked up first as this is value that isn't working as intended anymore. :-)