
Ask HN: How do you schedule fixes for new bugs during a sprint? - blumomo
When planning a new development sprint (for us one sprint lasts 2 weeks), we take in any known, serious bugs, new features and a couple of planned refactorings. Once the sprint gets started new bugs will pop up, most often very fresh ones that were discovered only after the previous sprint has finished. Bugs don&#x27;t wait for the sprint planning – it&#x27;s their habit to also show up at any time during the already planned and started sprint.<p>The challenge for us is now to take out already planned stories from the active sprint, in order to make room for those new bugs.<p>Except from tracking bugs in your favorite bug&#x2F;issue tracker, how do you factor in crucial bugs while your sprint is already running? Do you reprioritize the sprint stories with your team to compensate for the bug? Do you squeeze in the bug fixing and hope you can still stick to your entire sprint goal? What&#x27;s your methodology that works for your team?
======
verdverm
Prioritize things as needed, don't be so scrum board focussed, it's a tool to
help track and organize, not a playbook which is etched in stone on a Monday
for the next two weeks.

Do the work which matters most today. Damned are those who can't modify their
scrum board.

When I was on a DevOps team, we allocated 20% of our capacity for unknown task
which inevitably come up. Some weeks it was less, some weeks it was more.

~~~
blumomo
Thanks!

