Skip to main content

Minor changes (new errors found) in current sprint, in the same scope

Last post 06:15 pm July 27, 2021 by Thomas Owens
2 replies
01:53 pm July 27, 2021

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

thanks.


05:24 pm July 27, 2021

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?


06:15 pm July 27, 2021

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.


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.