Handling Interruptions in Scrum: 4 Options (Part 2)
There are four commonly known ways that teams use to handle production support, or other “interrupt” items. Frequently, these items are classified by “levels” of priority/criticality, with L1 being the lowest and L3 being the highest priority. As we continue from Part 1 of this two-part article, we look at the remaining two ways of interrupting Scrum sprints--and share what can be done about them.
3. Triage & Prioritize
This approach is most suitable when bugs/issues found in production are not extremely urgent. If findings are not life critical, they can be triaged by technologists (for size and complexity), prioritized by product owners and then be added to a backlog to be treated as all other PBIs (Product Backlog Items). This can be done during regular PBR (Product Backlog Review) sessions conducted by feature teams.
This approach is least disruptive to a team’s dynamics as it does not have any impact on a team’s velocity and cadence. A team does not have to dilute its focus and capacity that was allocated to sprint-based work by adding additional work mid-sprint.
This approach is frequently seen when a team is directly responsible for its production code (no L2 and L2 mid-layers). The product owner firmly controls communication with the business and is empowered to shield a team from undesirable interruptions and
Please log in or sign up below to read the rest of the article.
"All you need in this life is ignorance and confidence, and then success is sure." - Mark Twain |