Anti-Pattern: Defining Non-Project Roles in Scrum
As others have said, there's no role called "Bouncer" in Scrum. The Scrum Guide defines exactly three roles within the Scrum Team:
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.
Because a Scrum Team is cross-functional, the team can certainly choose to perform any activities that further its Sprint Goals, and can do that in any way that makes sense for the team. However, defining additional roles (rather than processes) is a Scrum anti-pattern that typically indicates an underlying process problem.
Your team is defining a role named "Bouncer" to perform triage and provide support. When you say:
A bouncer's role in this context is to:
communicate and track support,
investigate incoming issues, and
escalate as appropriate
you're clearly describing a recurring support function rather than product development or time-boxed work, which are the domains for which Scrum was designed. That doesn't mean Scrum doesn't allow for bug fixes or support; it just means that designing a support process outside of the Scrum framework and then shoe-horning it back into Scrum is generally The Wrong Thing to Do™.
In Scrum, all work must be prioritized on the Product Backlog, estimated during Sprint Planning, and should be related to the current Sprint Goal. In a properly-implemented Scrum framework, bugs or defects from outside the current Sprint are placed onto the Product Backlog, discussed and prioritized during Backlog Refinement, and then planned if and when they are in scope during Sprint Planning.
This makes sense because Scrum is primarily a project management framework, and its goal is to manage projects that have a defined scope and a limited duration. Ongoing support or repeating processes are not projects, and can be difficult to manage within a framework that is designed for time-boxes rather than procedural cycles.
In my opinion, bugs or defects in a project's product definitely belong to the Scrum Team, but should be handled within the Scrum framework. However, ongoing support should not be part of the Scrum unless a business decision has been made to permanently reduce the team's capacity to allocate a time-box for support within each Sprint.
A better alternative is to set up a separate support process, perhaps using Kanban or another cycle- or queue-driven agile methodology, which could then handle issues directly or feed them back into the Scrum's Product Backlog as appropriate. Conceptually, such a support process is outside the Scrum framework, but that doesn't mean it must be isolated!
Lessons Learned About "Support Scrum"
I've used Scrum for administrative, support, and back-office processes that aren't project-based. It can be done. However, the central feature of Scrum is the time-box, and support is not inherently driven by estimates or time boxes.
The only way I've been able to make Scrum work in such non-project endeavors is to:
- Zealously enforce time-boxing.
- Use one-week Sprints.
- Rigorously enforce Scrum ceremonies like Sprint Planning as the only valid inflection points for making changes to team goals.
- Make it 100% clear to stakeholders that any change in the current Sprint for "emergencies" invalidates any forecasts or commitments for the current Sprint.
- Understand that coherent Sprint Goals and rigorous prioritization will allow some tasks to languish in the Product Backlog for long periods of time.
If you're not okay with all of the above, then Scrum is not the right framework for your support process. Evaluate Kanban as an alternative for queue-driven work, or find another process that's more suitable for your business and political needs.
For more about how to handle ongoing or recurring support tasks within Scrum, or on why Scrum is often the wrong choice for managing an ongoing support process, see the following related answers: