Scrum (Backlog vs BAU)

This contentious point came up recently in some team discussions and it reminded me briefly of the challenges that I used to/had to face when I was part of another agile team.

The point that I was referring to is that of a Scrum/Agile team having to juggle and manage both enhancements and BAU support.

Looking back, my previous team was actually on-track and even over-delivered ahead of the set goal and the project was launched successfully. Although we had successfully cut over, this also meant that the team has to manage both new and launched features.

We had experimented with various methods with varying degrees of success tackling this problem:

1) Treat all production issues as stories and insert them mid-sprint based on criticality.

This method only lasted barely 2 sprints before the team called it off. BAU issues demanded urgent attention and are very adhoc in nature. As the product was just launched, teething issues and stability issues were always looming and demanded our attention. Without fixing them quickly, we would lose the customer base that we managed to secure and that also meant the product would lose traction and might risk being canned/dropped by management (no management wants a money losing initiative). As such, the disruptions were frequent and the development team found it near impossible to deliver any features planned and velocity dropped drastically.

2) Pre-estimate and accord an estimated number of story points per sprint for BAU support.

This approach was being tested for 2 sprints before the Product Owners were calling a halt to the trial. The estimates were always inaccurate due to the fluctuations in bugs/issues encountered during the sprint, and that affected how many storied could be planned & played within a sprint. The developers were also troubled by the non stop context switching which did not help the issue.

3) Splitting the team up to focus on both BAU and Enhancements.

This particular Agile team had a total of 12 pax (near to the max advised). Collectively we decided that out of the 9 developers (1 PO/BA, 1 Scrum Master, 1 QA/Tester, 1 Lead and 8 Developers), we were going to split them into 5 Developers focusing on enhancement and features whereas 3 Developers would focus on production issues/requests. Both the sub team still reported under the tech Lead who aligns and rotates them as required. The team finally settled on this arrangment which worked to balance the unique needs/wants of everyone. The tradeoffs were slightly lowered velocity but the team was able to focus and barely after 3 sprints; were again able to consistently meet/over deliver the story points and bugs and issues were given the necessary attention as well.

Morale of the Story

As I am writing this article, I hope it serves as a cautionary read for any teams encountering this. The need to understand what is the real issue and to balance and understand the implications of one approach over another. For teams that do not want to "trial" stuff that I have already gone through, can draw inferences instead and try out other variations of the above suggestions that serves to address your particular unique issue.