Quick Fixes
During a sprint should a team work on fixes that take a matter of minutes to complete and having nothing to do with the sprint goal? For example the user would like a delete button to provide a confirmation dialog or change the background of the page.
IMHO these quick fixes always take longer than couple of minutes when you account for discussion, testing, design, etc. I also believe that the number of quick fixes can quickly add up in a sprint and pull the team away from the sprint goal. Third, these interruptions disrupt the team from the sprint goal. Finally it helps the team understand that not all fixes are urgent and that as a team they are allowed to say no.
Thoughts?
I wouldn't consider adding functionality, such as a confirmation dialog, to be a fix of any sort. It's a new feature, which has been requested by the product owner, which should be added to the product backlog for prioritisation before being brought into a future Sprint.
(In fact, we had the same discussion - relating to a confirmation dialog - just last week.)
I agree with your opinions. On my project, it has been agreed that the the team sticks with the sprint goal as planned and prioritised.
I too have seen what are seemingly easy fixes soon become major distractions.
I suggest that the person asking for the change, (I am assuming either the Product Owner or someone from the business), needs to be aware of the impact it would cause to the rest of the sprint and that something would have to give. They would need to be reminded that the sprint is providing what was originally asked for under their priority. By all means make the change if the business still want;s it, but get their clear agreement as to what can and would fall from the sprint if the change takes too long to implement.
Hope this helps. John
> During a sprint should a team work on fixes
> that take a matter of minutes to complete and
> having nothing to do with the sprint goal?
No they shouldn't, at least not until the Sprint Goal has been met.
Once the Goal has been achieved, if there is time left in the Sprint, the Development Team can do whatever they like.
I was on a Project for a single customer. There he (the users) were able to give Feedback on an increment. This Feedback was part of the product backlog. A bug for us is a Kind of PBI.
From time to time we did product backlog refinement, but we give the developer a possibility for a short cut. When the investigate on a bug to clearify it and recognized that it was clear and the fix took less then managing it (estimating, discussing with the customer, doing the sprint planing for it, etc.), he was allowed to fix it instead.
I can recommend this short cut as it worked fine and reduced some management overhead.
Examples of very small bug might be typo on a label. Adding a Button is definitive no bug for us.
Kind regards
Benjamin
Thank you for your advice. I will continue to work with the team to stay focused on the sprint goal.