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.