Discussion topic: Doing production support and new work on the same Scrum team.

Facilitator: Armen Badeer - abadeer@assurity.com

Issue presented:  We're doing production support and new development on the same Scrum team.  Currently we're struggling to plan sprints effectively and not end up having to excessively re-prioritize during the sprints, or run out of room, causing delays in either the 'critical' / 'can't wait' production support issues or in the previously agreed-to new development items.  This is with an 8-member team running 2-week sprints.  This is also a new team doing Scrum for just a few months.

Ideas / discussion points:

• Shorter sprints - maybe 1 week?

   

• Separate teams - one for production support and one for new development?

   

• Rolling production support assignment to single member within team.  Plan a backlog item for that team member with an appropriate size for the 25% work expectation.  That member should do all the actual production support work themselves, but should go to other members for help as needed.  Also increases knowledge sharing throughout team.

   

• Plan for 75%/25% split between new development / production support time during a sprint.  Include these items on the backlog.

   

• Plan sprint capacity/velocity based on expected availability of team members being reduced for production support.  Do not include production support on the backlog for this option.

   

• Conduct a 'Stabilization Sprint' or even 'Stabilization week' for occasional 'catch-up' on production support, technical debt, or architectural issues that come up during regular sprints.

   

   

Other notes of import:

• The Scrum team should really be operating with a Service Level Agreement in place to assist with prioritization and context for conversations about the new 'critical' production support items.

   

• The Scrum team should feel free to communicate that they are feeling overloaded or in danger of not completing the sprint as planned.

   

• The Stabilization sprint could be used in coordination with the release schedule.

• 1 week sprints have less planning/review meeting overhead than might be expected once they are running.  They can help manage workload by being less disrupted by incoming 'critical' production issues.  This schedule requires good Product Owner involvement.

• Management and Product Owner support is required in order to be able to push back on adding new items to current sprint in some circumstances.