Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia. Read Statement
Minor changes (new errors found) in current sprint, in the same scope
Hi. I´m the PO in a software development enterprise. While testing a sprint (release candidate) we found a minor error not related before (no item in the current going sprint asked to correct that pre-existing issue). But that new error is in the same scope of the Goal of the Sprint and its correction is simple (just 4 hours of development). Nevertheless the development team refuses to append that correction in the current sprint. We´ll have to end the sprint, deliver our software with a known bug, and to fix the bug just in the next Sprint .... It doesn´t make sense for me. Please comment.....
It's up to the Developers to decide how much work they can take on in a Sprint, and what their capacity ought to be. No work can be pushed on to them. But they are accountable for ensuring that the work they do is of usable quality, and that an appropriate Definition of Done is met.
Is their work, with the defect you mention, of usable quality? If it isn't, have you discussed with the the team what negotiable scope they ought to drop, from the Sprint Backlog, so the Sprint Goal can still be met and the Definition of Done properly satisfied?
It is true that the Sprint Backlog "is a plan by and for the Developers". Once a Sprint Goal and Sprint Backlog are established at the Sprint Planning session, only the Developers can pull in additional, unplanned Product Backlog Items.
From a Product Owner perspective, I'd consider the impact of this defect. It is pre-existing in the system, so users are already contending with it. However, the work being done in this Sprint may escalate the impact or severity of the issue. As the Product Owner, I would recommend that you explain to the Developers what the issue is, how it is reproducible, and what the impact is toward the ability to achieve the Sprint Goal. If it's correct that the Sprint Goal would not be satisfied without this work being done, then the Developers should strongly consider pulling the work into the Sprint.
If I was the Scrum Master for this team, I'd be curious as to why the Developers are so hesitant to pull in this work, especially if it would jeopardize the Sprint Goal and the overall quality of the product. Cases like this are one of the reasons why I encourage teams to not allocate 100% of their capacity to the Sprint Goal. My rule-of-thumb is that the team should be able to accomplish the entire Sprint Backlog with about 60-70% of their total team capacity, and the Sprint Goal with about 70% of that capacity. This can account for everything from unplanned absences to overhead to unanticipated work, but still giving the team enough valuable things to do that if the risks don't materialize, there's no question about what options exist for what work to pull next.