Options For Handling Support And Maintenance Work In Scrum
Allocating Resources for Support Work
Setting aside dedicated capacity for incoming support requests is crucial for responsiveness. Teams can allocate certain team members to be primarily responsible for support work during each sprint. This ensures there is availability to promptly assist users and address issues. Another approach is creating a separate support team focused solely on user needs. This group would handle the intake and resolution of all production support requests.
Setting aside team capacity for incoming requests
Rather than making support work an afterthought, teams should preemptively allocate sprint capacity for handling user requests. For example, teams can designate 20% of the sprint specifically for support efforts. Team members would spend this percentage of each sprint responding to, diagnosing, and resolving incoming tickets from users needing assistance or reporting issues. Setting aside capacity upfront enables quicker response times compared to making support work secondary. It also makes the workload more manageable across the team.
Creating a separate support team
Organizations with sufficient resources can consider assembling a dedicated support team responsible for user needs after production deployment. This may be ideal for products with extremely high support volumes. Having a separate cross-functional team focused solely on user support allows the primary feature development team to concentrate maximizing new capability delivery. The support team would own the intake process for tickets, assist users with questions and issues, troubleshoot problems, and identify bug fixes needed. Members across both teams would need to communicate closely on recurring issues and productfamiliarity.
Managing Unplanned Work
Despite best efforts to plan, unforeseen support requests or critical production issues can arise, throwing off sprint commitments. Scrum teams have two main options to handle these scenarios – adding support needs into the current sprint or adjusting scope to reduce original commitments.
Adding items to sprint backlog
If new priority support requests emerge during a sprint, the team can consider adding these as official sprint backlog items. This allows the work to become visible, be accounted for in capacity planning, and progress can be tracked. Teams will need to remove or reduce scope on other sprint commitments to free up capacity for the newly added support items. All new backlog additions and scope changes should be communicated and agreed upon between the development team and product owner.
Adjusting sprint scope
An alternative to adding support requests directly into the ongoing sprint is to maintain the sprint backlog commitments as originally agreed upon. In this case, the team would adjust the scope of functionality delivered within the sprint to devote time and effort toward resolving the critical support issues. By reducing sprint commitments rather than overloading the team with more work items, the team avoids taking on more than their capacity permits. The product owner would need to indicate which existing sprint scope items to remove or scale back on to make room for support efforts.
Tracking Support Efforts
A key aspect in managing support work involves capturing details on incoming requests and time spent assisting users. Scrum teams have two primary options that integrate well with agile processes – logging support tickets into sprint backlogs for visibility and reporting actual hours dedicated to support across sprints to quantify the workload and inform future planning.
Logging requests in backlog
Support tickets can be managed in the standard product backlog system and prioritized alongside other work items. Adding support requests directly as backlog items enables product owners and teams to view demand, communicate priority, and track progress on resolving issues. Teams should categorize support items in the backlog for easy identification and filtering. Common conventions include labeling these as sub-tasks under overarching support or maintenance backlog items or tagging items with metadata like Support.
Reporting time spent on support
In addition to tracking support requests themselves, logging the actual hours team members spend handling support tickets provides useful data on capacity consumed. At the end of each sprint during the retrospective, teams should report the support hours, discuss trends, and determine if expectations need to be adjusted on support levels versus development capacity for future sprints. Monitoring support hours over time can uncover patterns to address.
Estimating Maintenance Tasks
Providing accurate estimates for maintenance work involves breaking down larger requests into executable items for the team and basing estimates on measurable historical data to inform realistic timelines.
Breaking down large requests
When facing support requests or maintenance needs that feel ambiguous or overly complex, teams should investing time to decompose these into discrete Agile backlog items for the next sprint prior to estimating. For example, a broad request like “Fix performance issues” could specify measurable sub tasks such as “Diagnose slow page load times” and “Improve database query performance by enhancing indexes”. Estimating at this work item level allows the team to evaluate required effort more precisely.
Basing estimates on historical data
Data on actual hours spent resolving prior support requests in each system area provides the foundation for realistic maintenance estimates. Historical data helps estimate tasks such as resolving a high severity production bug or enhancing functionality related to a particular system component. Teams can track benchmarks over time on hours required for different request types to continuously inform future estimates as additional data accumulates.
Automating Regression Testing
Implementing automated testing suites provides accelerated feedback on product quality following maintenance work, while scheduling tests to run with each new build further strengthens the safety net.
Implementing automated test suites
Scrum teams accelerating software delivery should make automating regression testing a priority. Test automation suites make executing repeatable tests efficient across sprints without relying on manual repetition. Automated UI tests provide validation from the user perspective after changes, while unit and integration tests ensure foundational functionality remains intact sprint over sprint. Consider automation gaps with each bug fix or feature change to incrementally expand test coverage over the evolution of the product.
Running tests with each build
Enable continuous validation by incorporating automated test suites within the deployment pipeline. Configure the pipeline to trigger automated tests with each new build and deploy version. Fixing issues as they are introduced is significantly more efficient than waiting until release candidates or production deployment. Optimizing this fast feedback loop between check-ins and test outcomes is key for rapid and reliable iterations.
Planning Time for Technical Debt
Legacy quality issues and architectural weaknesses contribute to higher maintenance costs over time. Teams can implement both periodic structured refactoring initiatives along with integrating some remediation efforts into continuous delivery workflows.
Scheduling refactoring sprints
To make tangible progress chipping away product technical debt, schedule periodic sprints singularly dedicated to upgrades, refactors, performance optimization, and test coverage expansion. These maintained-focused sprints give the team uninterrupted time boxes to pay back selected portions of technical debt backlog without conflicting priorities. Treat refactoring sprints like standard feature delivery sprints by committing to defined scope outcomes.
Prioritizing tech debt backlog
As quality and architectural shortcomings surface, log tech debt items into a dedicated, visible backlog specifying rework details alongside business value and effort estimations. Product owners can then transparently prioritize these items among new feature requests to plan into upcoming sprints. Evaluating total cost of ownership tradeoffs between enduring deficiencies rather than addressing them versus delivering new functionality without rework helps determine priority.
Communicating with Stakeholders
Clear communication on support details and expected response times helps align user expectations. Teams should inform stakeholders on support workload, priorities, and policies through visibility tools and direct outreach.
Setting expectations on response times
To avoid user disappointment, inform key stakeholders directly on standard response times and resolution targets for support requests based on severity and complexity. For example, communicate that minor cosmetic issues may take up to 3 business days to resolve, while blocking defects impacting major functionality will be prioritized immediately. Updates on actual average response times across classifications helps calibrate understanding.
Providing visibility into support workload
Dashboards displaying volumes of ongoing user support requests by status, assignment, priority trending over time build stakeholder empathy. Supervisors gain data to staff support capacity adequately. Transparency into support request influx and cycle times for commonly reported issues guides user expectations. Highlighting overall team workload distribution across new features versus enhancements versus defect resolution communicates priorities and progress.
Optimizing Processes
Analyzing root causes behind frequently recurring support issues helps prevent subsequent incidents. Continuous improvement of team practices further propels product quality and user satisfaction over time.
Analyzing root causes of issues
Treating each user-reported defect as an opportunity for improvement involves investigating underlying root causes for escaped issues. Dig into why the originally developed solution failed in production and what process gaps allowed this to ship. Perform defect analyses individually initially. Then aggregate common causal factors across incidents to guide systemic preventative action such as changing testing approaches, enhancing requirements gathering, improving configuration management or performing more substantive architectural reviews.
Improving team practices to reduce support needs
Optimizing processes around development, testing, and technical practices aids preventative defect resolution upstream. Pursue relevant continuous improvement initiatives such as expanding unit test automation, implementing peer code reviews, integrating security guidance into design reviews, and adapting usability testing. Strengthening fundamental team practices reduces escaped issues reaching production that eventually funnel into support unplanned work. Incorporate continuous improvement into each sprint retrospective.
