Question? (Scrum_Guide, S. Retro Or S. Review)

Last post 01:48 pm February 2, 2014
by Mehdi Hafezi
4 replies
03:22 am February 2, 2014

1) Introduction: in current Scrum Guide (published -July 2013) , page 10, in chapter Sprint Goal :

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

2) Question: If we ( S. Dev.) change with PO agreement the current sprint scope ( e.g. move one complex user story back to P.Backlog) , Is the following assumption correct?
PO together (with Dev. Team support ) has to check if the "Sprint Goal" is still valid and possibly updated it accordingly.

03:27 am February 2, 2014


It was send before I had change the subject, Is it technically possible to edit the subject of raised isse afterward?
Subject suppose to be : Question? (Scrum_Guide, Sprint Goal Updating during Sprint?)


03:59 am February 2, 2014

If the work turns out to be different than the Development Team expected, it implies that the work will not make the contribution (to the Sprint Goal) that was forecast.

The team would therefore seek to change the scope of the Sprint Backlog...not in order to alter the Sprint Goal, but in order to preserve it and the expected delivery of incremental value.

Such changes in Sprint scope do not involve "moving user stories back to the Product Backlog", although planned work can certainly be traded in and out of Sprint scope. PBI's that have been negotiated into a Sprint do not actually leave the Product Backlog, because by definition they remain undone and are still product inventory. The discussions between the Development Team and the Product Owner on changing Sprint scope can impact that inventory, and the PO may have to revise the user stories and acceptance criteria accordingly.

05:39 am February 2, 2014

Just to reinforce the point, the Scrum Guide says "A Sprint would be cancelled if the Sprint Goal becomes obsolete". That's an indication of how important it is to value the Sprint Goal...and of how important it is that the Sprint Goal provides value.

The trivialization of Sprint Goals is a *very* common problem in Scrum. This is why so many people at the Ha level of Shu-Ha-Ri say "why are we doing Scrum at all, with its wasteful ceremonies and Sprint Backlog batches" and gravitate towards Kanban. Although maturing, they don't quite get the point of Scrum and the value of the Sprint Goal in mitigating business risk.

01:48 pm February 2, 2014

@Ian: Thank you for clarification(s), Mehdi