The sanctity of the Sprint Backlog

No worries, Phil, thanks for posting!

I've stepped up into the role (which is something I've done before)

Which role? PO or SM?

Here is how I generally handle such things, and this is just one way to handle such things and stay in alignment with Scrum principles.

If it's considered more of a bug, then use this chart:
http://www.scrumcrazy.com/bugs

If it's more like a totally new requirement(performance requirements often are), then use this chart:
http://www.scrumcrazy.com/scope

Be careful hammering your manager with Scrum rules when you are the SM -- sometimes you have to decide between being "right" and being "employed."... and there is lots of room in between. Maybe you just ask the manager if he would like for you to handle it the "scrum way" to make sure the full scrum team is fully informed and following scrum.

In general, no, I don't like the idea that *anyone* has put items into the current Sprint Backlog without consulting the development team. OTOH, there may be emergencies where inserting emergency PBI's or bug fixes/production support is necessary, so the link to the charts I gave you above can give you some guidance there -- but both charts will tell you that the Dev Team and PO must be involved in the decision.

Did I answer your question? Have any follow ups? Do the charts help at all?

Charles

Maybe you just ask the manager if he would like for you to handle it the "scrum way" to make sure the full scrum team is fully informed and following scrum.

should read:
Maybe you just ask the manager if he would like for you to handle it the "scrum way" to make sure the full scrum team is fully informed and following scrum. By giving him the chance to say "yes" or "no", you may be avoiding a job safety problem for yourself. Remember, you *are* a servant leader to the Scrum Team. Sometimes the best you can do is make the impediment visible(transparency).

While I always advocate following the Scrum principles, I also advocate for people to consider whether they want to be "right" or "employed," and anything that jeopardizes your job safety, IMO, should be avoided if you value your job/role. Sometimes you can make impediments visible in a very respectful way -- and sometimes doing even that threatens your job safety -- it' s a judgement call for you.

Thanks for the reply, Charles.

The role I often step into is that combined PO / SM role. Its not a fun place to be, and I really appreciated it when I've had a separate PO. Dividing conflicting interests into separate roles does make getting a clearer ordering easier...

I take your point about job security. There are a number of things that my manager and I don't see the same way, these being one of them. So far I believe I've kept it amicable enough, whilst pointing out what I disagree with. It is a difficult, fine line to draw.

The charts were very interesting, and helped a lot, thanks. The PBIs he'd added to the sprint are mostly fairly small, so should be relatively easy to incorporate into the sprint. There is one in particular that is ill defined, so I'll discuss it with the team at the standup, and my manager when he comes on line again.

It occurs to me that this is where Scrum becomes more "framework", and less "process"; it needs to be rigid enough to helpful, but flexible enough to deal with the unknowns.

Phil

Thanks for the reply, Charles.

The role I often step into is that combined PO / SM role. Its not a fun place to be, and I really appreciated it when I've had a separate PO. Dividing conflicting interests into separate roles does make getting a clearer ordering easier...

I take your point about job security. There are a number of things that my manager and I don't see the same way, these being one of them. So far I believe I've kept it amicable enough, whilst pointing out what I disagree with. It is a difficult, fine line to draw.

The charts were very interesting, and helped a lot, thanks. The PBIs he'd added to the sprint are mostly fairly small, so should be relatively easy to incorporate into the sprint. There is one in particular that is ill defined, so I'll discuss it with the team at the standup, and my manager when he comes on line again.

It occurs to me that this is where Scrum becomes more "framework", and less "process"; it needs to be rigid enough to helpful, but flexible enough to deal with the unknowns.

Phil

The role I often step into is that combined PO / SM role.

I generally recommend against combining those roles, but I imagine you already know that. :-)

It occurs to me that this is where Scrum becomes more "framework", and less "process"; it needs to be rigid enough to helpful, but flexible enough to deal with the unknowns.

Yes, exactly, you're definitely getting the gist of things. What I find the trickiest is handling "real life problems" that are not specifically addressed in the Scrum Guide, and yet trying to still stay in line with Scrum principles and rules. It's not always easy -- which is why I created the charts -- again as *one way* to handle those situations. Please don't take the charts as the "only" way or in any way an official part of Scrum. (I tried to put enough disclaimers on the chart to make that clear!)

> My understanding is that stories selected for the Sprint are "gold":
> only adjustable by the team, in conjunction with PO. Nobody but the
> team make changes to them (however the PO can abort the sprint
> if it no longer makes sense). Is this correct?

That is correct, the Sprint Backlog is adjustable by the PO in conjunction with the team. No-one else, not even the ScrumMaster, is authorised to make that adjustment. It is almost always accepted that the PO can abort the sprint, but there are differences of opinion on this which do surface in various guides and books.

> Currently he and the PO are overseas at a client, and I've stepped up
> into the role (which is something I've done before)

An SM can stand in for a PO during Sprint Zero (before a PO may have been assigned) in order do things like populate a first-cut of the Product Backlog. However it is irregular for an SM to stand in for a PO once a PO has been assigned. To do so breaks the rules of Scrum...an SM and PO can't be the same person. However, I'd say it is reasonable for an SM to *proxy* for a PO on an exceptional basis if the PO is indisposed.

> ...his actions seem to directly conflict with what I understand to be
> the sanctity of sprint backlog. Its not up to him (or me!) to add to or
> remove work from the sprint without discussion with the team. By
> all means, add them to the Product Backlog, and order them near
> the top, just don't divert the team from their current goal

You are absolutely right. My response to such behaviour would be to abort the sprint (since you were proxying for the PO in his absence, you have that authority). A softer option (still agile, but not strictly Scrum) is to treat the sprint as a trading space, and to say "OK, if that new stuff is going in, what do you want taken out to make room for it?". Work of equivalent story points is potentially tradeable. Of course, this requires mid-sprint replanning involving the team, the time for which must *also* be taken into account during the re-estimation exercise. And don't forget the revision of the Sprint Goal. This is an opportunity to teach an important lesson, which is that failing to respect a sprint boundary incurs cost.

"by the PO in conjunction with the team"
The team wholly owns the Sprint Backlog.

"An SM can stand in for a PO during Sprint Zero"
What about this mythical Sprint Zero makes the roles of SM and PO
interchangeable and eliminates the conflict of interest intrinsic in their
objectives?


On Wed, Nov 28, 2012 at 12:42 PM, <ScrumForum@scrum.org> wrote:

>

The team wholly owns the Sprint Backlog. The PO can't change it unilaterally, he or she can only progress a desired change in conjunction with the team. The authority lies with them.

Interchangeability of SM and PO roles is qualified by Ken Schwaber in his "Agile Project Mangement with Scrum". He points out (Appendix A) that "In the absence of either the Product Owner or the Product Backlog, the ScrumMaster is required to construct an adequate Product Backlog prior to the [Sprint Planning] meeting and to stand in for the Product Owner."

I suppose he actually means *any* sprint planning meeting at any point in the project. However, due to the conflicts of interest between SM and PO roles, I'd constrain it a bit further to sprint zero (no matter how mythical it may be) and to exceptional circumstances (e.g. PO sick/abroad) if it credibly allows an associated impediment to be managed.

Ryan,

The team wholly owns the Sprint Backlog.

By "the team", did you mean "the Dev Team"?
If so, then I'm in 100% agreement with you on that.

On Ian's comments regarding the PO adding stuff directly to the Sprint Backlog, and scope changing mid spring, I would be very careful about aborting the sprint. Aborting these sprint is a very rare event, and in my view, should only be done if some extraordinary event happens like: a company re-org or buyout/merger that means most of the current sprint work is useless, a large shift in business direction that means most of the current sprint work is useless, any action that significantly changes the "Sprint Goal", etc.

I think some Scrum principles here to follow is this line from the Scrum Guide:
"During the Sprint..."
"...Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned..."
"...No changes are made that would affect the Sprint Goal..."

Hi Charles

Yes, aborting a sprint is (or should be) a very rare thing. As the Guide points out it can be traumatic for the team. Hence my outlining of a softer option. I believe that a strict application of scrum rules would involve cancelling the sprint, but I base that on the (possibly incorrect) assumption that the interference would indeed have made the Sprint Goal obsolete.

Re-reading my post, I'd like to make the following clarification. It is just as much of a learning opportunity for the *team* as it is for the manager who interfered with the Sprint Backlog. Just because a manager wants to make a change to the backlog, it doesn't follow that the team should swallow it. Instead they should refer the matter to the PO.