Working in an agile teams, it's common to have to triage ad-hoc work, general questions and also bugs, while having regular sprint work too. In fact some workplaces might have a dedicated person on a roster to do this, to "shield" the team from distractions and allow them to get their usual sprint work done. Some teams I've been in call this being "Batman". Which is like being on call. There can also be an optional "Robin" sidekick, and as explained below there is nothing wrong with asking for more help when needed.

While it might sound simple, a lot often goes on, particularly in weighing up business priorities, timelines and clarifying what is at hand.

Generally most batman bugs should go in to BAU (business as usual bugs) for review, unless there is a business reason that it is urgent.

Once an issue or query is found, to work out the priority it's always good to ask:

  • how does this affect the business eg is there a loss of money or reputation?
  • to tease this out in more detail, you could also ask  what is consequence if we do not fix/investigate this?
  • is this an existing bug?
  • how long might it take to fix?

It's also good to define what Batman might be. For example:

  • As hinted at above, Batman is a way to scope ad-hoc work to one person, rather than the whole team - but there is nothing else specific to the batman role.
  • It is just a person that is expected to be the point of contact for external requests during a sprint.
  • Batman is there to handle anything that is not in the current sprint.
  • Batman also completes any urgent work deemed to be part of the sprint after the triage process.
  • Batman should respond to questions on chat channels.
  • The work that is in testing is part of the current sprint, and the tickets are already assigned. It is not Batman's job to ensure everyone is updating JIRA tickets. Though when issues come up related to recent work, having up to date JIRA tickets can be invaluable, so Batman might ask team members to update JIRA.
  • It is also not Batman's job to pick up any bugs raised by testers which occur as a result of current sprint work. Developers should test everything. PRs should obviously only be submitted for code that has been tested by the developer, and that works and satisfies acceptance criteria.
  • Testers are the last line of defence, they are there to test more scenarios not picked up by unit, integration and functional tests, potentially taking more time to do - but the code should already satisfy the basic requirements of the story.
  • Batman may end up in conversation with testers due to ad-hoc questions, but if a question is related to an existing ticket, Batman is fine to pass those questions on to the relevant person working on the relevant feature.

Once something is found, elaborating on the above initial questions:

  • For things that are deemed significant enough, we can reach out to the business, like the product owner, to check if they can/should be done in the current sprint.
  • For the ones that we deem to be just minor bugs, they can just be in the backlog, with sufficient information - without explicitly bringing them to Product Owner's attention.
  • For the ones that we may deem to be worthwhile resolving in the short-medium term, we may want to advocate for their inclusion in an upcoming sprint. The Product Owner should be looking at the backlog and prioritising on a regular basis anyway.
  • A lot of the discussion specific to individual bugs could take place in JIRA comments - whether it is batman summarising what the current question/conclusion is, or whether it is tagging people to ask a question.

If tasks that entered the sprint end up being dragged into multiple sprints - it is probably up to the team to decide whether to treat those as ad-hoc work for Batman to verify, triage and possibly fix, or whether to create a new ticket.

All that being said, all the above are initial guidelines. It is fine to be agile, for example to pull something in to the sprint with good reason, but then pull it out later if new information comes to hand. The key is always to have solid reasons and lines of communication.