Agile Philly

Committed to helping members build better software

Response to article "Applying Agile in a Mixed Feature Development and SLA-Bound Bug-Fixing Team"

What is your experience dealing with product maintenance while managing development in a Sprint? This article was posted on the Scrum Alliance website.

Applying Agile in a Mixed-Feature Development and SLA-Bound Bug-Fixing Team

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.


Shorter sprint

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.

Single-day sprint

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:

  • 1st minute of the day: Product owner provides a list of tickets that need fixes, plus pending features.
  • 20th minute: Team holds a sprint planning session and commits to tickets and features for the day.
  • 4th hour of the day: Team provides a small update (e.g., "Fixed this ticket and ready to go live") to others in an informal way.
  • 7.5th hour: Team winds down committed tasks for the day.
  • 8th hour: Team moves the day's work to a staging machine and demonstrates all fixes done for the day, then ends the sprint.

This way the complete turnaround for a ticket is one day and the team is inside the framework.

Hardening sprint

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:

  • Understanding the root cause of maintenance issues
  • Automating your testing
  • Code refactoring and maintainability

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!


Views: 771


You need to be a member of Agile Philly to add comments!

Join Agile Philly

Comment by John H. McHugh on March 13, 2018 at 6:22am

John, thank you for the response. I'll mark my calendar for April 27th. 

Comment by John Voris, Lead Coordinator on March 12, 2018 at 11:05am

SLA Service Level Agreements did come up at the last AgilePhilly meeting on "Fixed Price Agile Contracts" by Mike Harris.  And see Mike Harris at the AgilePhilly Springtime Conference downtown on Friday April 27th.


At AgilePhilly, we have been Promoting Agile Ideas since 1776

AgilePhilly is a not-for-profit user group of volunteers in the Philadelphia area dedicated to better software development practices.


Meetings are monthly. Get meeting reminders by joining here.  

  • Our events are Free but you must RSVP.  We have Evening Meetings in the Western Suburbs, usually on the Third Tuesday.  They usually begin at 6:30 pm.  A sample agenda would be:
    • 6:30-7:00 pm: Eat & Greet & Network
    • 7:00-8:20 Main Topic/Speaker
    • 8:20-8:30 Q & A , Pack-Up, More Networking

  • Our Sponsors cover the cost of pizza / sandwiches for an evening.

Our attempt with the group is to provide an environment where you can exchange ideas and meet with individuals involved in agile community.

© 2024   Created by Ravindar Gujral.   Powered by

Badges  |  Report an Issue  |  Terms of Service