Clarify whether in-sprint change is OK, or verboten - and effect on acceptance criteria
Guide says that "Sprint Goal gives the Development Team SOME FLEXIBILITY regarding the functionality implemented within the Sprint" and "if the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint."
This change seems pretty significant but wasn’t addressed in the webinar or summaries of the 2017 guide changes. It seems a reversal of traditional guidance to minimize or eliminate changes to functionality during the sprint, to expose improvement areas and encourage transparency.
Also, does the “work” –refer to tasks, or the actual story content?
If this IS a change, suggest that the sprint commitment and acceptance criteria be written generally, so that the PO and team have discretion to implement something in the spirit of the goal, rather than to the letter.
This also requires full transparency between the team and the PO to so as not to undermine empiricism and the reliability of performance metrics. The team shouldn’t strong-arm the PO to loosen their acceptance criteria; nor should the PO go too easy on the team. If the team didn’t understand a requirement or a process thoroughly enough, and the PO lets them off, they may miss the opportunity to inspect what went wrong and adapt accordingly. Yet if the PO didn’t really understand what they were asking for, perhaps they should be flexible and add a clarifying story to the product backlog for future implementation. The Scrum Master really needs to be on top of his or her game!