We have an On Support rotation cycle where someone in the team owns our queue for any incidents/requests for a week. Though we are trying to get better at Scrum, i feel that this helps the team reserve that time for someone specifically to work on those issues/requests. I ask the team to only commit to items on the sprint based on their support schedule. We have not yet used the Sprint Goal to prioritize these requests that are sometimes small projects, that was great input!
We do the same thing on one of my scrum teams. We have four devs - one takes Tier two support for the week and makes themselves readily available. If support is very slow or handled by tier one, they begin to help on smaller sprint backlog items - most of the time this is a prioritized bug/tech debt item.
I would have a 10% buffer there for interruptions! Empowering the PO to say no or not right now has also being helpful. facilitating a meeting with the PO and stakeholders to look at the backlog together really helps with managing expectations. Tech debt happens at times but test driven development, and daily clean code helps. But most importantly not rushing your team to finish quick, helps them to really produce quality work.
during our sprints we started to notice that some bugs that existed for like... 2 years but nobody noticed, and then they suddenly appear... they're usually consequences of poor architeture decisions, this kind of bug we usually send to the product backlog, and if the client really needed something related to that feature, we evaluate if there's a short term/fast solution to his problem, and i mean to emphasize that in these cases we try to solve the problem, not the feature's bug, most of the times his problem can be solved without fixing the feature. But for me, the worst case of interruption, is when there's something that deppends on something external to our company/team, like another company, and we just can't schedule properly, so they just sudden appear and say "we will be available tomorrow" so the team has to work on that PBI that was not planned for the sprint, just because otherwise we may not have the chance again.
That happens to my scrum teams all the time, and the worst is that these projects normally means a lot for the company, so we can't just don't attend to it... I'd really like to have a solution for those situations!
I treat this as a standard. Those things happening - that's it. It's PO task to adapt Product backlog after new things come up and until product backlog is adapted and aligned with stakeholders I'm fine with that. $$$
We have an On Support rotation cycle where someone in the team owns our queue for any incidents/requests for a week. Though we are trying to get better at Scrum, i feel that this helps the team reserve that time for someone specifically to work on those issues/requests. I ask the team to only commit to items on the sprint based on their support schedule. We have not yet used the Sprint Goal to prioritize these requests that are sometimes small projects, that was great input!
We do the same thing on one of my scrum teams. We have four devs - one takes Tier two support for the week and makes themselves readily available. If support is very slow or handled by tier one, they begin to help on smaller sprint backlog items - most of the time this is a prioritized bug/tech debt item.
@@michaelhandley8013 what’s a tech debt?
I would have a 10% buffer there for interruptions!
Empowering the PO to say no or not right now has also being helpful.
facilitating a meeting with the PO and stakeholders to look at the backlog together really helps with managing expectations.
Tech debt happens at times but test driven development, and daily clean code helps. But most importantly not rushing your team to finish quick, helps them to really produce quality work.
Assess if it is really a priority, if it is then other ongoing work has to give and be carried into the next sprint.
during our sprints we started to notice that some bugs that existed for like... 2 years but nobody noticed, and then they suddenly appear... they're usually consequences of poor architeture decisions, this kind of bug we usually send to the product backlog, and if the client really needed something related to that feature, we evaluate if there's a short term/fast solution to his problem, and i mean to emphasize that in these cases we try to solve the problem, not the feature's bug, most of the times his problem can be solved without fixing the feature.
But for me, the worst case of interruption, is when there's something that deppends on something external to our company/team, like another company, and we just can't schedule properly, so they just sudden appear and say "we will be available tomorrow" so the team has to work on that PBI that was not planned for the sprint, just because otherwise we may not have the chance again.
That happens to my scrum teams all the time, and the worst is that these projects normally means a lot for the company, so we can't just don't attend to it... I'd really like to have a solution for those situations!
I treat this as a standard. Those things happening - that's it. It's PO task to adapt Product backlog after new things come up and until product backlog is adapted and aligned with stakeholders I'm fine with that. $$$
What are the alternatives for a Scrum (Kanban) board to visualize Sprint backlog?
Perhaps move it to the next sprint? If the interruption can delayed until the next sprint, I’d try that.
I'm torn because we are supposed to welcome emergent work. How do we strike a balance?
Can you cover topic agile / scrum Security integration I'm interested in combining security with scrum /agile
When should a sprint be interrupted ?
Step 1: Pause and discuss anything that comes in not part of the negotiated and committed sprint goal. Default behavior.
Not yet > No.
I always grey out a 25% of my sprint.
Why
@@cutflow2 contingency time…