Bug fix in the agile scrum is a buzzing issue to discuss that we all love to avoid. We use tools like JIRA and scrum board to estimate bugs. But do we want to estimate bugs? Do we really need to?
To understand this aspect properly, we will first need to revise the artifacts of SCRUM. SCRUM has sprints. and for each sprint, it has a fixed backlog that the development team commits to. And it is thriving to produce a functional increment of the product in the sprint.
Now, how do the bugs really come? Bugs can come from mainly two scenarios. The development team has completed a story. During the sprint, the team has found a problem with the completed story. As a result, a bug/issue has been raised. In this context, do we really need to estimate bugs? The more important question would be, when do we actually estimate it? As there is a bug, it means the functionality that the team has produced is not done. So the story cannot be done/completed. Until all the issues related to the story is done away, the story remains open, even if the sprint reaches its end. At this point, the sprint goal won’t be achieved and the PBI (Product Backlog Item) item number will not decrease.
The other scenario- the team hasn’t found any issue during the sprint and the story was completed during one of the previous sprints. Now during the ongoing sprint, the team has found some issues. So how do we really handle this? Sprint backlog cannot be changed as PBI tracking will not be accurate. So the issue can not be handled in this sprint. So we put it in the next sprint.
During the next sprint’s planning meeting, will the team give any estimation? For any kind of estimation to be done for the backlog items, we know that the team has to analyze the stories, understand the problem they are solving, and then plan how many stories they want to do this sprint. But for a bug to be estimated, the team needs to analyze the bug first to understand what is causing the bug to be produced in the first place!
Estimating bugs takes a lot of time (not in all but a lot of cases). When we have investigated a bug enough to make a proper estimation, we could have also fixed that bug at that time.
Now we might say that there are some bugs that we easily know how much time it will take to solve. For defects like these, what we can do is that we can allocate a chunk of time from the sprint to solve as many bugs the team can solve. And this could be at the beginning of the sprint. Jeff Sutherland uses at PatientKeeper half a day of the sprint to solve the bugs remaining from the previous sprint. There is a healthy discussion on stackoverflow on estimating the bugs.
But most importantly, we need to ask the question- if there is something so trivial is left behind, are we really following scrum properly? Are we really delivering functional product increment at the end of the sprint? If our retrospective is being done properly, we would be coming with these answers very early in the sprint. Only then we would be able to save time to implement functionality rather than wasting time to estimate bugs that are not even properly analyzed.
What about the production bugs or critical bugs that come from the end users? If we are following SCRUM as we should be, we will be delivering functional products and the probability of finding this kind of issues is very rare. And when we find this kind of blocking issues, this needs to be handled outside of the scrum team. You can not add a new item to the backlog, so how do you handle it? What if you only have only one scrum team and it needs to be handled right away. In that case, we can assign one or some team members, who have the profound knowledge of the item that is associated with and get it done in a separate branch -preferably as a hotfix. Or after discussing among the scrum team members, keeping in mind about the severity of the issue, the product owner can cancel the sprint for bug fix. But this has to be one of a kind exception, not as a process. They should also keep this item to be discussed in the retrospective. And in the retrospective, it should come out how it came alive in the first place and what needs to be done to avoid it in the future.
Scrum asks are we adding value to what we are doing? More often bugs occur because of technical debts, and as a result, does not bring new business value (it shouldn’t exist in the first place!), so why waste time on estimating something that doesn’t bring value to the customers? It should just be a part of the velocity, so time-boxing to reduce the waste of additional estimations is actually a good idea.
Timeboxing:
For a bug that needs to be analyzed, assign a random hour to investigate and solve that. If the team is able to fix that inside that timebox, it’s all good. But if it’s not possible then the team needs to discuss this issue according to scrum guide.
-No changes are made at this point that endangers the sprint goal set at the beginning of the sprint.
-The scope can be renegotiated between the product owner and the development team, that means escalating the issue as soon as possible.
In the end, SCRUM is all about adding value to the customers. The time spent to estimate bugs adds less value to the customer. It would have been better spent that time on creating a functional product by adhering to the scrum principles from the very beginning. When we focus more on estimating something like bugs, we are forgetting about the core of agile – Individuals and interactions over processes and tools. Just because estimating is available in issue tracking tools like JIRA and TFS, you don’t have to use that. Estimating bugs and taking that into process violates the very core agile is formed on.
If you have liked what I said here or disagreed with the article please leave a comment so that we can have a healthy discussion. And if you want to know more about SCRUM, please download and read the free SCRUM book.