For those of us that work as Scrum Masters in tech development companies we sure get good use of SM knowledge. We plan in sprints, we do stand-ups and keep a good feeling amongst our devs.
However! Every now and then we have a project that earns our stress and a bit of lack-of-love. I find some issues when we have a nice planned sprint and things are going good. A tickets falls into "QA review" and passes with flying colors. Then comes "UAT Review" or "customer review" whatever you know it as. My problem with UAT is that when a client finds an issue, it's sent back into "In progress" and F-up the sprint for the week or 2.
I've tried asking the customer to send issues or non-urgent bugs into backlog but hasn't listened.
I'm finding it hard to get a good process for the sprints and wanted to see if there's any other SMs around here so we can talk. Saving Changes...
If a work item from the sprint backlog is the cause of a defect (either with that feature OR as a result of a regression), then that work item should not be considered "done". In such cases, it is completely reasonable for the additional rework effort to be considered part of the sprint.
On the other hand, if it is an issue unrelated to the work items being completed which is a very rare occurrence assuming the UAT effort is part of the customer's review process for completed work items, then having this independent defect added to the backlog would make sense and if the PO feels it is worth pursuing in the current sprint, they can certainly negotiate with the team to swap that defect for a sprint backlog work item which is of roughly the same size...
I would say you need a better defined process for how you plan what changes go in which sprint. It should be done collaboratively, rather than one party dictating what gets fixed where. That can derail your entire plan as you're discovering.
Issues found in the UAT is very common in large complex systems. In aircraft for example, individual components are tested by themselves, then integrated into labs, and then we often have to flight test so the systems process real data rather than simulated data.
The issues discovered are categorized based on their severity. It takes a pretty big issue on the program critical path where we must implement the fix immediately. A nuisance problem that does not affect functionality should not disrupt the more urgent work and goes in the backlog. A potential significant safety issue could stop testing until it is fixed and affect the whole program schedule.
Depending who your customer is, telling them no could be a challenge. Having the hard data to say here is why this change must be fixed when is important to justify the timing priorities. If you drop everything any time a minor issue pops up, it will pull people away from most important issues that determine the ultimate success of your project. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Lot of things can be commented on your post. First, acceptance criteria defined and writting into each user story is a must. This will prevent lot of headaches when UAT takes place because they acceptance criteria is wrriting with the users. Second, at the first time, if you are using a Kanban board to monitoring the flow of the work, take into account the columns you will define which will be the stages each user story will stay. Third, no problem if some user stories on the sprint are not able to be completed. What is important to be aware on that and alert on that as soon as possible. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
If you have a work item in your sprint that is not working well, it should retain its priority above the remaining backlog. (You do prioritize your work items, right?)
If reworking the work item will delay lower priority items in the current or following sprints, then you need to communicate that back.
Finally, you may want to consider integrating user acceptance testing right into your team. That would not only allow you to detect and correct defects sooner but it would also allow you to use a test-driven development approach. Saving Changes...
Keep in mind that the purpose of Scrum is not to run sprints or have the next X number of sprints perfectly planned. Among other things, you should be trying to:
- deliver value quickly, to the customer
- learn and adapt quickly
If the customer/product owner wants to change the backlog for the next sprint before it starts, based on what they feel adds the most value, that's how it's intended to work. Now, if there is a disparity in what you think adds value and what the customer feels adds value, it might be time to have a discussion about value. One, or both, of you may need to adjust your way of thinking. It's possible the customer may not understand the long term impact or that rolling the work into the next sprint can change what was going to be delivered by the end of the sprint. It's also possible that having stable code is more valuable to the customer. Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
There is a fundamental problem with the flow and the ability of stakeholders to manipulate the flow. In scrum, the team manages their work i.e. they decide what should be in 'progress'. Your process should have a WIP limit that either prevent or raise a flag if it is exceeded and not all stakeholders should have the option to put items in progress. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
To add on the good comments made here, it also is a mindset issue: Try looking at any ticket, bug, issue as being a valuable feedback.
It is a change to your 'well-planned' sprint.
It helps you and user/customer understand each other better.
Consider yourself as a translator between user/customer and developers.
Mindsets are also perspectives. Being more and more able to change perspectives is a good capability which reduces stress, enables solution and creates trust. And increases empathy.
Design thinking helps, Ed de Bono's 7 hats help, outside the box thinking helps, traveling helps.
Community Champion
