Committing the Product Owner to a sprint backlog with a contract

Question

A short introduction to the question: I'm a Scrum Master in a small web development organization (10 employees) and we do a lot of projects that'll last for 3 or 4 sprints, with an average duration of 2 months total.

I'm currently in a situation where we actively involve the Product Owner during backlog refinement meetings and sprint plannings, even though some of the companies we work with were hesitant at first because they're not familiar with the Scrum framework. That being said, they were happy to to tag along as it gave them a lot more control of the proces. The problem is: although they know the rules about not changing the sprint backlog during a sprint, most of 'em change the backlog at least once every sprint. Their intentions are good ("we found out a different color works better, change it" / "Our client wants to test in browser X today, please make a testing server now" etc) but they don't seem/want to understand that this will impact the work we can finish during a sprint.

Now we thought it would be a good idea to let the Product Owner sign a sprint release contract, containing key dates, the sprint backlog and definitions of done. While researching scrum theory we kind of assumed the presence of the PO in sprint planning meetings and a verbal agreement to commit to the backlog was enough, but in reality that's not always the case.

My question: is it a good idea to let the PO sign a contract containing the sprint release details? And is there any example of such document in Scrum literature I can reference?

Answer 1

TL;DR No, because what you describe is not strictly Scrum - you should fix the process instead of inventing a workaround. The PO can change the product backlog, but not the sprint backlog. If the team does not agree with the required change, or cannot implement it without endangering the sprint, PO may cancel the sprint (and incur all associated costs), or let it be and put a new story on the product backlog to address the changes.

is there any example of such document in Scrum literature I can reference?

The main document for you is a Scrum Guide (http://www.scrumguides.org/scrum-guide.html). I'll refer to it several times below.

The problem is: although they know the rules about not changing the sprint backlog during a sprint, most of 'em change the backlog at least once every sprint.

According to the guide,

During the Sprint:

• No changes are made that would endanger the Sprint Goal;
• Quality goals do not decrease; and,
• Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

and

Only the Development Team can change its Sprint Backlog during a Sprint.

If the change asked by PO is endangering the sprint goal, then it should not be accepted. You as a Scrum Master is in charge of that. Your backup in conversation with the POS is the Scrum Guide.

they don't seem/want to understand that this will impact the work we can finish during a sprint.

That's your job as a Scrum Master to explain it to them. Likely, they actually understand that it impacts your work, but do not pay enough attention to it.

Now we thought it would be a good idea to let the Product Owner sign a sprint release contract, containing key dates, the sprint backlog and definitions of done.

No. No and no. Again, by the guide,

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

Your definition of done is a contract. The sprint itself is a time box, which cannot be changed, only cancelled.

To sum up, you should work with the PO and explain the rules of the process that you are trying to follow. Introducing additional "contracts" shows a lack of transparency and trust, and those are the things that should be addressed.

Answer 2

Sprint contracts, such as you describe, should not be used, as it defeats the purpose of Scrum/Agile. Instead, do the work up front to ensure the project can be run properly. To do so, the following (at minimum) should happen

1. Ensure the client is properly educated in Scrum before the project starts. Ideally, this begins to happen in the pre-sales/sales process.

2. Spell out delivery methodology ground rules in the project charter. Ensure that the client knows that, by signing the project charter, they give their blessing for the project to be carried out according to the charter. Changes to the charter should require somewhat formal process. The charter change process, and potential risks of any charter changes, should also be spelled out in the original charter.

Answer 3

No, its not a good idea, as it defies one of the core Agile principles:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Cancelling a Sprint:

If the changes are so big that it brings the sprint goals in danger tell the Product Owner to break up the sprint and start a new one. The costs should be that all unfinished work is lost, make sure the price is clear. Afterwards the PO can decide to continue and finish the current sprint and put the extra work on top of the backlog or stop the sprint and start a new one with the new gained knowledge.

Also see canceling sprints in the Scrum guide for more information:

Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

Kanban:

Maybe Scrum is not the thing for your clients and they prefer more flexibility. Take a look and compare Scrum vs Kanban. Focus on getting started work done before taking up new work, but change the short term backlog continuously as it fits the need of your clients.

Answer 4

Would shortening the sprint help protect the goals, this of course incurs more planning overhead but might give the customer the flexibility they need. Perhaps a mid sprint re-plan might give you more predictability around late coming changes.

Contracts are probably not the right way to go as has already been pointed out as Agile welcomes change. If the sprint work is chunked up, is it possible to pinpoint what won't get done as a result and agree that with the customer when the change comes in. Perhaps that with a change cut-off period, say 4-5 days prior to sprint end might help things.

Answer 5

Systems like scrum are conventions that people have agreed upon in order to create a reasonable confidence in their (near) future expectations. A sprint effectively provides reasonable guarantee/confidence in what you can expect to see at the end of the sprint.

That being said, plans can always change. We can never exclude that the customer has a valid concern that warrants messing with the planned sprint. For example, your developers might need to urgently be called away on another mission that could not have been foreseen but still outranks the current development goal.

Technically, scrum does not prescribe this happening. It assumes that a sprint is set in stone and does not change. But reality can be very different. And that's perfectly okay, but it comes at the cost of acknowledging that this effects the planned sprint and therefore the (near) future expectations can no longer be reasonably guaranteed.

Personally, I leave this up to the person with the highest authority in this discussion. The sprint can be messed with if necessary, but not without accepting that the guarantees made during the sprint planning are effectively null and void.

One small exception: I would allow for minor things such as changing a color, if you haven't even started on that ticket in your sprint yet, or if the fix takes less time than explaining why you're not going to do it (in a figurative sense). There's no point bickering over really harmless things if their impact is negligible.

That being said, your situation might be different. For example, the person who is relying on your planned sprint might not be the same person who is now calling for the sprint to be messed with. That is a very different beast to tackle, because it first requires you to refer the latter person to the former.

Without approval, I would not let the sprint be messed with by outsiders. With approval, you can refer back to the earlier point that it must inherently mean that the sprint goals are null and void.

This is my take on how to approach development in general. I'm mentioning it because it helps explain the points I'm making in the next section.

---

A contract is not the way to go here, in my opinion. It is needlessly formal, and it is going to foster a defensive attitude. You cannot treat a sprint the same way that you would treat a fixed price contract (where you do indeed take this exact approach: sign for the requested work and never deviate from it).

What you're trying to do here is to waterfall your individual sprints, which is not only going against the original goal of doing scrum, it can also bite you in the ass when you fail to deliver a goal for whatever reason. A PO who is forced to sign a contract pretty much against their will, even if they agree to it in the first place, is likely to ask for damages upon non-delivery of the entire contract. Do you really want to roll those bones?

However, there may be contractual considerations between your company and the client company that supersede this. For example, if the client company is liable to pull the entire contract plug if you fail to either meet a sprint goal or fail to jump to their whims, that's a situation that's doomed to fail.

If, for whatever reason, your company is not in the position to enforce a reasonable limit on this behavior, then you might need to strongly enforce a communication format between your company and the client - but I would argue that at this stage the relationship has deteriorated into one of no trust and systems such as scrum or agile simply do not work in such an atmosphere. You'd almost inherently have to fall into a waterfall approach where every iteration is rigorously defined and agreed upon, to an almost legal degree, before you start working on it.

---

Overall, I would urge you to foster a cooperative spirit with your PO, explaining to them the consequences of messing with the sprint; and if they insist on doing so, that they must inherently consent to nullifying the current sprint goals (i.e. they will receive a subset, but not the full set, of goals that were set out).

If they don't agree to that, then you shouldn't agree to do anything that wasn't planned in the sprint.

If both options fail, and your company is not able to simply step away from this client and look for an actually scrum-friendly client, your last resort seems to be to end the scrum approach and opt for a waterfall approach instead.