A question from a recent workshop:
Within the Scrum framework, how would you typically handle maintenance work?
Answer:
Here is how I handle it with my teams. I use a Scrumban approach with swim lanes. The top portion of the board is a standard scrum board and the stories for the 2-week sprint flow through to Done-Done status. Since my teams do not break User Stories into tasks, we do not have a column for tasks.
Our columns are as follows:
- Sprint User Story Backlog
- Sprint User Stories In Progress
- Sprint User Stories To Test
- Sprint Complete
The bottom of the board, however, is segmented off with the same columns but with WIP limits. Then If the team feels that 2 members should be able to cover maintenance issues for the next sprint, then 2 members who did not work on maintenance in the prior sprint volunteer for this sprint. This allows knowledge to be shared among all team members.
Therefore, if maintenance items come in, they immediately go into the Kanban backlog at the bottom, and these flow through straight into deployment as most maintenance Items in our case cannot wait 2 weeks but must be done now. If maintenance items slow down, then those who are assigned to the KanBan tickets with free time will move up to the regular sprint board until another ticket appears which is their priority.
This process has worked really well on 3 different projects. The only downside is that the velocity will not be stable. As a Scrum Master, I work with this and average it out sprint after sprint. For me, things have worked well with this.
We are agile.
Author: Ed Rubuliak
Web Site: https://theagilemasteryacademy.com
email: ed.the.scrum,professor@gmail.com
Facebook Group: https://www.facebook.com/Agile-Software-Development-482874298764658/
