Are you distressed by the huge amount of defects in the product? In this article, you will learn about what practical possibilities you have in agile teams and managing error correction.
One of the first questions that pop up whilst introducing agile is how to deal with errors. Too often I hear an immediate answer:
‘Agile is not appropriate for fixing mistakes, it is a nonsense, impossible and unwanted.‘
In reality, there are more than many possibilities. To clarify, we are going to talk about how to fix errors that occurred in the previous product iterations. Errors found in the current sprint should be fixed immediately. In this case, it is a subtask of a user story in the current sprint where misfunctions have been found.
Option 0: Bug backlog
Product owner keeps track of business requirements in a product backlog and bugs stay in another pile. In a bug backlog as Bugzilla, Mantis or other bug tracking tool.
The advantage for clients is an opportunity to continue with already existing tools and an option of divided prioritization of bugs.
The disadvantage is working with more backlogs. The product owner loses track of priorities.
Do not ever fix bugs like that!
Option 1: Reaction
When a bug occurs, the product owner places it in a sprint. He should have the willingness to put it off for later sprints and not include it in a current sprint. As much as possible. If it’s not, he should include it but only with a consciousness of a team.
The best thing is for the team to try to evaluate the difficulty of a bug, so the product owner has a concept and knows how to change priorities according to that.
Teams usually start with a „fast lane“- a kanban board area reserved for unplanned activities. At the start, the fast lane is typically 20% of team capacity. The value changes depending on the current situation, e.g. for the deployment of a new version, it can be more if the team expects more defects.
Such rows on the board (swimlanes) can be more. Kanban defines swimlanes as a Class of work. And such Expedite is solved immediately, compared to the others, e.g. with a fixed date and a lower priority. Read The Kanban Glossary to understand Kanban-related terminology and principles.
Note: It is a big fail if we expect mistakes after deployment. Think about how to not make bugs instead!
The disadvantage of this method is that we often feel the need to answer the question, if we are still in the fast lane or if we had already passed it. ScrumMaster often draws the additional ideal line on the burndown graph. One for the overall capacity and one for the capacity without the fast lane. The real line should be somewhere in-between. Scrum project management framework does not support tools like that.
Another disadvantage is that customers, stakeholders, feel like everything will be supplied, which in many cases does not have to be the truth.
The advantage is a fast start in a new team with Scrum, an existing option to react to bugs, an overview of added defects, easy measurement of quantity, and the ability to adjust in the next sprints.
Option 2: Filled bottle
The second option, which happens to be the one I prefer, is to fill the sprint fully. In consonance with team capacity, which is the team able to finish and according to velocity, of course.
If I, as a Product Owner, decide on a correction, I go to my team and ask them, if it is possible to fix the bug in a current sprint. If it is, the team tries to estimate the correction. Based on the fix I, in the role of the Product Owner, pull the same complexity of the sprint. From the end of the sprint backlog, the least important.
The advantage is that it hurts.
If I add something, I will not expect to have something else. I have to prioritize what is more important and what not so much. In this light, the bug is not as prioritized. The team has to think about it as well. During that process, the true importance is shown. To not disturb the team, I bring bugs often on the daily stand-up. But only if we are on fire or “losing breath”.
Another advantage is that the error is being put in the order with cards that are already in the sprint, by me. I am prioritizing.
The Burndown graph shows the remaining work constantly. All I need is one line and I know exactly where we stand at.
The disadvantage is that by the end of the sprint I have a different scope as I planned to. But because I am doing that as a PO, I know exactly what and why was to move away.
Option 3: Bugy kanbánero
Well, sometimes there will be a crisis, and all you can do is cancel the content of the sprint and move on to Kanban mode in the sprint. The product owner adds up and prioritizes daily, the team fixes by the order. We do not plan a sprint but measure and evaluate the state. Either with a burndown graph or the cumulative flow chart.
How do we fix mistakes in ScrumDesk?
ScrumDesk, our own project management tool, is being developed with Option 1 and 2, for example. We combined multiple because sprint is much more dynamic in our company than it may look. Basically, we already function with Kanban, when priorities can be set 3 weeks ahead, but they often change for business. We try to have a static interval for at least a week.
In a case of errors, this is our process
Important Bug is a line, in which we have all of the important and urgent errors. The ones that affect many customers at the same time and in addition are critical and prevent them from using our product.
Another line Bug#26 contains errors of which correction has been planned for Sprint #26.
Errors are no longer divided into subtasks, they are usually dealt with during the first day. And that is why one card is enough for us. But it is important to mention that the test and other things are included in it as well.
Proactively instead of reactively
The most important part is to go from a mode of reaction to finding out the errors to planning the correction of errors.
Start with deleting/closing every error that is older than 1-3 months. Really! Do not be afraid, they are old errors, which may not even longer be an error, considering the code has changed, or the person is no longer at work or no one even remembers them. If it is still an error, it will appear again.
Look for the root causes of the problem
Why are there errors in your code? In what part? How many? How important are they? What financial impacts do they have? What costs can be saved?
Maybe you will have to turn on code coverage if you have tests. If you do not, then analyze.
In ScrumDesk we do it with RCADesk, which enables to map the problem for us, break it into smaller pieces, identify causes and record action steps, either in a graph form or a mind map.
Urgent does not mean necessary
When an error occurs I try to leave it for later. The client can often wait, all you have to do is communicate properly.
We take into account importance rather than the urgency of an error.
- Important and urgent errors fix right away.
- Important and non-urgent as second.
- Unimportant and urgent as third.
- Unimportant and non-urgent. Not fixing at all?
Do not make mistakes
Sci-fi? It will not be 100% but it is worth a try and investment.
Even the opportunity of dealing with errors gives a feeling of being able to solve it ‘somehow’ when they occur.
To be a Scrummaster, we have to observe such behaviour of the team. Signals.
How to reduce the risk of making errors? Agile provides many tools and practices:
- Definition of Ready, so all requests have needed information and team provides what is necessary.
- Readiness indicator for every request, so Product owner knows if he had done a good job preparing and discrepancies were indicated soon in the process and he still has time to complete them.
- Regular sprint preplanning, where he can find out.
- Code review, compulsory. Everywhere and always and every time. Rotate at the review, do not always point out the same region of a code.
- Pair programming. Special in the most complex parts.
- Automated testing. Period.
- Regression tests. Fast and detailed, different test suites.
- Rules of writing the code. Old, but still good.
- Static analysis of the code. To trunk without a warning.
Conclusion?
Fix the errors found in the sprint right away. Prioritize other errors with importance and urgency. Important is more important. Compare the priority of an error with the content of a current sprint. Try to plan fixes for a next sprint. Do not creep the scope of the current sprint. If it is not possible, try to discuss it with the team, estimate the fixing time and move it into a right place in the sprint. In ScrumDesk we always put it in the first line of Kanban board, so we can fix it as soon as possible and create a space for originally planned requirements.
Should you do it the same way? Is this the best way? I do not know if it is, for you. Think about it, because agile means adaption.
