What is your experience dealing with product maintenance while managing development in a Sprint? This article was posted on the Scrum Alliance website.
05/21/2012 by Albert Arul Prakash Rajendran
Note: This article is based on a Scrum Alliance Google groups thread called "How to apply scrum in a mixed feature development and SLA-bou[n]d bug fixing team." I have compiled most of the solutions that were provided in the thread. Not all parts of the article are my contributions.
In most software development organizations today, there is no dedicated sustaining engineering (SE) team to take care of post-release maintenance and support. The engineering (R&D) team doubles up to complete SE tasks in addition to feature development. However, support service-level agreements (SLAs) with maintenance-paying customers are usually rigid, so SE often takes higher priority than R&D. Engineering teams that follow Scrum then fail to deliver committed features due to the high influx of SE issues and the need for their speedy resolution. Juggling between feature development and bug fixes also adversely affects team morale and motivation levels.
The following Scrum-based options were suggested by group members to overcome the problem in such situations.
Dedicating members for SE in every sprint
Using this option, one or two team members per sprint are dedicated to SE issues in a round-robin fashion. This eliminates the need to juggle tasks, and the team retains its morale and motivation. As all team members take turns working on SE tasks, they get insights into code quality, recurring development issues, and the cost/effort to fix issues post-release. Over time, this can result in a natural improvement in code quality.
Furthermore, since the capacity of only the remaining members is considered for feature development, this method ensures that sprint commitments are largely met. In case of low SE influx, the SE-dedicated members can fix other internal bugs and thus raise the overall product quality.
The team prioritizes all SE tasks and takes them up in order of priority. Using Kanban minimizes the work-in-progress items, because each member is allowed to work on only one task at a time. This model does pose certain challenges with respect to accurately forecasting the product release cycle, but it also significantly improves product quality.
The sprint duration is reduced to one week, and bugs are prioritized each week. The success of this approach depends on SLA expectations.
Divide and conquer
The team velocity is distributed evenly between R&D and SE. The team works with two simultaneous product backlogs, one for feature development and the other for SE tasks or tickets.
SE tickets, along with their SLA goals, are brought into the Scrum ceremonies in a similar manner as development stories. For example, there may be a story to improve response times to meet SLA. During sprint reviews, the team studies ticket metrics to determine if SLAs were achieved. The team has ITIL (information technology infrastructure library) built in as part of its definition of done and as part of its Scrum board. A scheduled task is created as a reusable story and goes through the Scrum process.
There needs to be some flexibility here to change goals during the sprint if required, in case there's a major incident mid-sprint. But if capacity is well allocated between plan-driven work and incident-driven work, reprioritization is rare.
This is a new approach to resolve the problem when SLAs are extremely stringent and none of the other approaches are viable. A single-day sprint is one that starts in the morning and ends that evening and includes all the standard components, such as sprint planning, velocity calculation, and review. However, the sprint retrospective may take a backseat or may be done on an on-demand basis.
The single-day sprint model looks like this:
This way the complete turnaround for a ticket is one day and the team is inside the framework.
If the team continues to be overburdened with a high influx of SE issues, it's time to talk to management about the possibility of running a couple of hardening sprints to fix existing issues. If run properly, improved product quality will result in a significant potential cost saving. A hardening project focuses exclusively on fixing issues. No new features are developed. This reduces the number of issues and the team gets some breathing space.
In addition to all the approaches listed above, investing in the following areas will lead to better results over time:
Group discussion brought up all these possible solutions, and there are likely other innovative ideas out there. If your team found some, let's hear about them. Meanwhile, all the best!