How do I resolve an unidentified issue affecting customer experience when a sprint has already commenced without impacting the sprint backlog? For example, I am currently in a sprint and a serious issue was identified by newly onboarded existing users on an app(migrating to a new app). New users are meant to provide additional documentation at the point of onboarding, presently existing users are also required to provide these same documents which is creating an uproar. There is a progress bar that shows the documentation progress for new users, which is also displayed for existing users. So, this progress bar needs to be removed immediately
6
-
1Can you add a little more details to your question, please? It's not clear exactly what problem you are facing and what kind of answer you are looking for, at least not to me...– BogdanAug 12, 2020 at 16:33
-
What do you mean by "unidentified issue"? Are you talking about bugs or about a change request coming from the customer?– LlewellynAug 12, 2020 at 19:03
-
Unidentified issues are issues or bugs not identified by the tester during a regression test– JudithAug 12, 2020 at 19:12
-
In that case, have a look at pm.stackexchange.com/questions/26616/…– LlewellynAug 12, 2020 at 19:26
-
To be more explicit, I am currently in a sprint and a serious issue was identified by newly onboarded existing users on an app(migrating to a new app). New users are meant to provide additional documentation at the point of onboarding, presently existing users are also required to provide these same documents which is creating an uproar. There is a progress bar that shows the documentation progress for new users, which is also displayed for existing users. So, this progress bar needs to be removed immediately– JudithAug 12, 2020 at 19:51
|
Show 1 more comment
2 Answers
First things first: If you have a show-stopping bug, your first priority should be to fix it. If the time spent on fixing the bug means that you won't be able to complete all your stories or meet the Sprint goal, so be it.
(Of course, if you realize that the goal is becoming completely unreachable, you might decide to scope out some stories or even halt/abort the Sprint. Either way, you can use the Retrospective to discuss why that happened and how to prevent it in the future.)
However, in general, time spent on bug fixing should not threaten the Sprint goal because that time should already be accounted for in the planning. Every Sprint, your developers will have to do things that don't directly contribute to the Sprint goal. Some of these can be planned for (e.g. recurring meetings, trainings), others can come up unexpectedly (e.g. critical bugs, having to support a colleague with something). Still, try to plan for both. You might not know how much time exactly will be spent on doing these kinds of tasks, but after a number of Sprints you (or your developers) will have a rough idea and know not to plan for 100% capacity but something much smaller than that.
The very first thing to do is to evaluate if the problem is really a show-stopping bug, or if fixing it could wait a few weeks.
If fixing the problem could wait a few weeks, the bug should be added to the backlog and be prioritized along with all the other work. Depending on the team's policy and the impact that the bug has, this means that the bug will be picked up in one of the next sprints (or even never if the impact is low enough).
If this is a "fix it NOW, we are losing money by the bucket" problem, then the team should decide on who is best suited to tackle the problem (regardless of what work is in progress and how far along it is) and re-plan their daily work around that.
Once the team has an idea of the impact that this has on the sprint, a decision needs to be made if the goals are still realistic, if any work not related to a sprint goal can be dropped and if it might be wise to abort the sprint and replan around the new reality.
answered Aug 13, 2020 at 8:20
