Sprint Bouncer role

Question

Our engineering team uses agile scrum and we are finally growing enough to be able to delegate more scrum roles to more members, including to some of the engineers like myself.

One role we're introducing that I have volunteered for is what we're calling the "bouncer."

A bouncer's role in this context is to:

• communicate and track support,
• investigate incoming issues, and
• escalate as appropriate

A work queue separate from the sprint is available for bouncers to work during downtime. This queue are small, low-priority tasks that do not impact business needs or sprint goals. These task's progress are to stop so that the bouncer may honor their role.

I am looking for more a much more formal definition of this role, and any information about it that I can get my hands on. Is there such information? Does this role go by other names that yield better search results?

Answer 1

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™.

Support Functions

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:

1. Zealously enforce time-boxing.
2. Use one-week Sprints.
3. Rigorously enforce Scrum ceremonies like Sprint Planning as the only valid inflection points for making changes to team goals.
4. Make it 100% clear to stakeholders that any change in the current Sprint for "emergencies" invalidates any forecasts or commitments for the current Sprint.
5. 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.

See Also

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:

• https://pm.stackexchange.com/a/6513/4271
• https://pm.stackexchange.com/a/14774/4271
• https://pm.stackexchange.com/a/8542/4271
• https://pm.stackexchange.com/a/8115/4271
• https://pm.stackexchange.com/a/21902/4271

Answer 2

It looks like you are describing a classic support role outside of the Teams Sprint. Triaging the support queue so as to leave the scrum team space to do their main work.

Kudos to you.

Perhaps you should look into setting up a Kanban board to support your triage work?

But to formally answer your question ,,, there is no such agile scrum role to describe the work you are doing. This is because the Scrum framework is light one that allows flexibility for teams to implement it in a way that works for them.

Regards

Answer 3

Scrum prescribes only three roles: Scrum Master, Product Owner, and Delivery (or Dev) Team.

That said, nothing stops the team from deciding how they want to tackle the challenges they face. If having someone take on these responsibilities is working for your team, cool. However, you won't find any formal definition.

One question I do have though is why, when not triaging support, you wouldn't just assist other team members in sprint work. It seems like you may be artificially separating yourself from the team.

Answer 4

Scrum only provides three roles: Scrum Master, Product Owner, and Development Team. No other roles are defined in Scrum. Since Scrum does allow for some elements of each role to be delegated, you may choose to give a name to the role assigned to the person who is delegated certain tasks and this name would be up to your organization.

The Product Owner role is responsible for Product Backlog management, and it sounds like most of these tasks fall squarely into that realm. Specifically, the Scrum Guide says this about the Product Owner:

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

If issues are being reported from outside the Scrum Team (which consists of the three roles), then those issues have an impact on the Product Backlog. Things like bug reports, changes to existing features, or new feature requests would be new or modified Product Backlog items.

Do note that the Product Owner may delegate some of these responsibilities to the Development Team. Of course, doing this will reduce capacity for the team. However, involving technical people sooner may lead to more well refined Product Backlog Items going into Sprint Planning sessions. This is a tradeoff that the team (or sometimes the organization) needs to make.

One thing that you mention, "communicate and track support" may also fall into the role of Scrum Master. The Scrum Master does provide support to not only the Development Team, but also the Product Owner and the organization. The Scrum Master should be helping the Product Owner find ways to deal with these incoming requests and methods to appropriately manage the Product Backlog, including writing good Product Backlog items. The Scrum Master is also responsible for making sure that any impediments to the Development Team are removed.

---

All of that definition-of-Scrum aside, you can identify other tasks that need to be done during the course of a Sprint and who will be responsible for handling them. And it's up to you to appropriately identify these roles and find good ways to delegate them, either on a permanent or rotating basis.

Personally, I think that the Product Owner, perhaps with support from one member of the Development Team (perhaps on a rotating basis) and the Scrum Master, should take the lead on these items. Investigating incoming issues and turning them into Product Backlog Items is definitely a Product Owner function, which may be delegated. Working to resolve impediments is definitely a Scrum Master function, which may include appropriate escalation. Tracking support may be a shared responsibility, but I would consider this to be a task that should be done by the Scrum Master to allow the Development Team to focus on development rather than tracking other people's work.