Skip to main content

Quick Fixes

Last post 11:51 am October 5, 2015 by Matt Thomas
5 replies
04:47 pm October 1, 2015

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?


06:27 am October 2, 2015

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.)


08:58 am October 2, 2015

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


01:50 pm October 2, 2015

> 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.


04:59 am October 5, 2015

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


11:51 am October 5, 2015

Thank you for your advice. I will continue to work with the team to stay focused on the sprint goal.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.