adjusting sprint backlog during sprint

Last post 10:33 am June 11, 2014
by Ian Mitchell
6 replies
Author
Messages
01:13 pm June 10, 2014

hi,

i'm having trouble here with an assessment question from Scrum Training Manual by Management Plaza which looks like following:

The Development Team realizes that the volume of work of one of the items in the Sprint Backlog is estimated incorrectly, and the current volume of work of the whole Sprint Backlog is 130 instead of 100. What should we do?
A. They should return some items back to the Product Backlog to keep the Sprint Backlog volume to about 100 points
B. They should ask Scrum Master for more time for this current Sprint
C. They should ask Product Owner to decide on this
D. They shouldn’t do anything now

Correct answer suggested by Manual is D with the following explanation:
The Sprint Backlog is frozen when the Sprint Planning is done, and no one can change it for any reason. In extreme cases, the Product Owner has the authority to cancel the Sprint.

Given that Scrum Guide suggests that Development Team may work with PO to adjust the Sprint work selected if they committed too much (there is a question even in Scrum.org open assessment) during a Sprint, how does this relate to the explanation given by Management Plaza Manual that sprint backlog is frozen and no one can change it?

I'm thinking that expression "sprint backlog is frozen" is not a valid point an maybe this has to do more with not altering the sprint goal. So Dev Team is allowed to make adjustments to Sprint Backlog working with PO, as long as this does not alter sprint goal.

How would you answer the question from above?

Thanks,
Adrian

02:18 pm June 10, 2014

I would stick to the scrum guide. As you pointed out:

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. 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.

Take note that it's up to the team to decide wether or not they can meet the commitments of the sprint. If it turns out that some goals cannot be met, the PO should definately be informed so that commitments can be renegotiated or canceled altogether.

Since the metric is in "points", you cannot use that to accurately plan wether or not the goals can be met. Within the sprint, there is more information available to the team to use to determine if they can make their commitments.

With that said, I don't see A as a valid answer.

B isnt valid because sprints are timeboxed and of fixed length.

C isnt valid because it is up to the dev team determine progress towards their commitments, not the PO.

D isnt flat out invalid but also isnt clear cut valid for reasons you've pointed out.

As such, D is the "better" answer of the 4.

07:00 pm June 10, 2014

I'd go with A... what's the point in trying to complete more than the team can - would that not just cause them to cut corners and introduce technical debt ?

Also, I'm struggling with the idea of "The Sprint Backlog is frozen when the Sprint Planning is done, and no one can change it for any reason." - something might not be needed any longer, so would you still build that 1 item

06:15 am June 11, 2014

I won't choose A, because it is not up to the dev team to decide on their own with item will return to the PB.
I won't choose B, because the sprint length is time boxed
I won't choose C as it stand : I will inform the PO, and maybe the PO + the dev team will decide together what to do (or not to do) by now.
I won't choose D as is stand, because the dev team should have the courage and transparency toward the PO. We don't have the full context, but maybe the item will not be finished, but the sprint goal will be met.

06:52 am June 11, 2014

C is the best answer, however it should read "They should inform Product Owner and renegotiante with him". This may result in A, but they cannot start with A without informing the Product Owner.
All other answers cannot be true: B violates the Scrum Framework, and C violates the Scrum values openness, courage and committment.
The "correct" answer and explanation given by Management Plaza is hilarious.
This is not the first occurrence in this forum.
I don't know why people keep on refering to them.

10:06 am June 11, 2014

Statement:
"Correct answer suggested by Manual is D with the following explanation:
The Sprint Backlog is frozen..."
Where does it come from? I just found in the Scrum Guide:
"No changes are made that would endanger the Sprint Goal"

So I would think the best way is to adapt and refine the Sprint Plan (with the PO) to meet the Sprint Goal.

From the Guide:
"The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog."

Imagine what happens if you have not planned all the selected PBIs in your Sprint Planning? Time was up. So you have to get started with your work and live with the incompleted Sprint Backlog. You have to close the gaps during the Sprint and work with the PO on it.

From The Guide:
"The Product Owner can help to clarify the selected Product Backlog items and make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner."

So in my opinion the Statement that the Sprint Backlog is frozen is just wrong. For me this comes near to answer C where the Team renegotiates the selected Product Backlog with the PO, but the PO decides what is acceptable to reach the Sprint Goal.

Kind regards

Benjamin

10:33 am June 11, 2014

> Correct answer suggested by Manual is D with the following explanation:
> The Sprint Backlog is frozen when the Sprint Planning is done, and no
> one can change it for any reason.

This is absolute nonsense.

> So I would think the best way is to adapt and refine the Sprint Plan (with
> the PO) to meet the Sprint Goal.

Correct, that would be the appropriate course of action. The estimates can be updated, and the Sprint Backlog revised, but there is no need to remove any work from an agreed backlog unless the Sprint Goal is in jeopardy.