Managing BAU tasks in the Scrum Team

User Story

As a <BAU Scrum team>

We want our <maintain the product by doing support and fixes>

So that <product does not lose its value for the customer>

Once the application has been deployed in the organisation they have to be enhanced and maintained. For the purpose of this article we refer to these projects as BAU (business as usual) projects.

Enhancement and new features are added as backlog items and prioritised by the Produce Owner. However when it comes to BAU items they are like known-unknown. We know there would be some maintenance work but we don’t know how much there would be and what kind of work would be involved. So how does the team manage the maintenance work?

Examples of work that fall under the maintenance

• There are issues in the system which degrades user experience or productivity.
• Issues which introduces risks, some of which can be managed by controls/workarounds.
• There would be routine investigation of issues reported which could lead to fixes required or user training / documentation.

As part of the maintenance, the team will have to provide support for the issues raised by the users. Support activities are not quantifiable in terms for stories. There is no estimation that team can do during sprint planning. Some team prefer to represent support as a backlog item for the purpose of sprint burndown. Tip: Set aside the time for support and adjust the team capacity accordingly. Teams should track the time spent on support to inspect and adapt the development capacity.

Support activities are like checking the pulse of the patient. It tells the team what things are obstacle for the users. Most of the issue raised during the support should go into product backlog and prioritised along with other items. But there would be times when the issue need to resolved immediately. Tip: Scrum team should not shy from change in scope of the sprint. One of tenants of agile is responding to changing requirement. They should however be tracked as they would provide feedback on areas of application requiring attention.

Daily Scrum

In the daily stand-up the support should update

1. What did you do yesterday? All the issues reported yesterday.
2. What will you do today? Any open issues from yesterday. If there are no issues from yesterday, there could be opportunity to pick some other item from sprint backlog. Tip: Don’t pick critical items as there is always a chance that you don’t get to work on it due to new issues raised during the day.
3. Are there any impediments in your way? What prevented or took longer for investigating the issues? For example not enough information available, test environments not available. Tip:These impediments are clues for scrum master of the system impediments.

Tip: Scrum events are time-boxed and daily scrum is not the place to analyse the support issues. Once the daily scrum is over, continue with group of people who want to contribute.

Backlog items

The backlog items created should have the user story describing the problem this presents to the user. Support is an opportunity to build empathy for the user and should be captured in the story. Story should be estimated by the team in the same sprint before being added to the backlog. Tip: If the item is related to incorrect behaviour of the system, presumably team have good knowledge, they should add enough details for team to pick up without requiring further refinement.

Tracking

Support is primarily an unplanned activity. It therefore requires to be more visible(tracked) and inspected. Capture time spent on support as this feeds into determining teams capacity for the planned sprint items. Tip: Create a separate lane for items handled by support. In this lane triage items based on their criticality.

Conclusion

Support activity covers entire gamut of the application. T-shaped team would benefit in this area. There would be time when SME would be required to be involved. Again this should be accepted as everyone is working towards the team goal. When team is working of a single queue, reallocation of time or re-priortisation of items is easier to manage. Support provides vital clues for where the system and processes need to be adapted.

Tip:Both, enhancement and maintenance, are important for the application to be relevant for the customer. Enhancements add value to be relevant. Maintenance help to retain value to be relevant. Product owner should consider balance between both of these type of items in their prioritisation to provide continuous value to the user.

Originally published on LinkedIn.