Scrum Breakfast

A marriage made in heaven…? Or hell?!

Contracts are often about one party establishing control over the other party. What if two equal partners are collaborating on something together?
Desired Benefit Join forces to achieve a goal that neither party could achieve alone without defining a hierarchy between the partners.
Structure Two partners invest in a product of joint interest. Money is unlikely to flow directly between the partners in the development phase, but each party must have a ROI, which may come from revenue sharing or just benefits from using the software.
Scope Defined to suit the needs of the partnership.
Risks Two of everything. Decision chains can get long. Rivalries can develop between the teams. Different models for extracting value from the product can lead to different priorities and differing willingness to invest. What happens if one of the partners doesn’t contribute as expected?
Tips Treat the joint venture as a separate entity: One team, co-located, with deve…

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…

Bonus and Penalty Clauses look good on paper but work better with things you can build out of concrete.

If you are building to a critical deadline, delays might not option. This approach assumes that extrinsic motivations work. If you incentivize people to deliver faster or penalize them to if they deliver late, then they will deliver faster, or so the theory goes.


Desired Benefit Incentivize the supplier to deliver faster.
Structure The supplier receives a bonus if the project completes early and pays a penalty if it arrives late. The amount of bonus or penalty is a function of the delay.
Scope Changes Difficult to accept because changes potentially impact the delivery date, which is surely not allowed.
Risk Does the customer have an incentive for early completion? The ROI arguments must be compelling and transparent. Otherwise, the customer could use a delaying strategy to lower the cost and exploit the penalty clauses to their advantage.  Is it more important to figure out the rig…

A Phased Development contract is similar to how venture capitalists work with start-ups. It keeps stakeholders in the loop while delegating most decisions to the product team.

Phased development is essentially a longer-term perspective on Time and Materials with Variable Scope and Cost Ceiling, especially if each phase is kept relatively short, e.g. three months or so.

Desired Benefit Enable decision-making within the project while maintaining control at the governance level over the costs.
Structure Fund quarterly releases and approve additional funds after each successful release.
Scope Changes Not explicitly defined by the model. Releases are in effect time-boxed. The knowledge that there will be another release next quarter makes it easier to accept postponing a feature to achieve the time box.
Risk Customer’s risk is limited to one quarter’s worth of development costs.
Relationship Cooperative. Both the customer and the supplier have an incentive that each release be successful …

For customers that aren't used to working with Scrum, this might feel like a leap of faith, because they don't know exactly what they will get in advance. But I believe this is a fairly pragmatic approach. Enabling the Team and Product Owner to make decisions about the product increases the likelihood of building the right product.




Desired Benefit: Enable decision making within the project while maintaining control over the costs.

Structure: Same as Time and Materials except a cost ceiling limits the financial risk of the customer.

Scope: Same as a Fixed Price, Fixed Scope project.

Decision-Making: Much more likely to be in the Scrum team, because decisions are made during the project about what functionality shall be included.

Risks: The budget will expire without achieving the necessary business value for the customer. Customer won’t get everything they ask for.

Relationship: Cooperative. The combination of limited budget and variable scope focuses both customer and vendor on ach…

Sometimes I call this, “heads I win, tails you lose.” Any outcome that does exactly use all the budget results in less profit for the supplier.



Desired Benefit: Cap the risk of the customer, offer the possibility of cost savings (though not providing much incentive to either party to do so).

Structure: Same as Fixed price, Fixed scope, except if the vendor gets finished early the project costs less because only actual effort is invoiced.

Scope and Decision-Making: Same as Fixed Price, Fixed Scope.

Risks: This appears to represent the ‘best of both worlds’ from the customer’s point of view. If it requires less effort than expected, it costs less. But once the cost ceiling has been achieved, it behaves like a fixed price project.

Relationship: Dependent. From the supplier’s point of view, the goal is to hit the cost ceiling exactly. There is no incentive for the supplier to deliver below the maximum budgeted cost. The customer has probably treated the project internally as a fixed price pro…

Sometimes I think this is the “holy grail” for consultants: Permission to work forever, predictable profits and all the risks carried by the customer. It also seems to be popular with large government contractors. Good work, if you can get it.




Desired Benefit: Achieve a goal when the problem is highly complex, not easily specifiable. Create a relationship to work together rather than merely deliver a particular result.

Structure: Work for a month, then send the customer an invoice. Suppliers like it, because the customer carries the risk of changing his mind.

Scope: Not a-priori fixed. Sooner or later, the customer doesn't want to pay any more, so the project comes to an end.

Risks: The financial and delivery risks are carried 100% by the client. Supplier has little incentive to keep costs down. Effort to ensure that only legitimate effort and expenses are invoiced can be substantial. Innovation in this context can be challenging because competitive innovations are likely to be disru…

This question has challenged the Agile community since the beginning: How do you do a fixed-price, fixed-scope project? Especially the big customers think they know exactly what they want, so their suppliers should be able to tell them exactly how long it will take and how much it will cost. In practice, neither of these beliefs are true.



Desired Benefit: Clarify all the questions so the purchasing decision can be made on price. Move the risk for time and budget overruns to the supplier.

Structure: Agree on the deliverables, deliver it. Send a bill. Customers like fixed price projects because it gives them security (or at least they think so).

Decision-Making: Generally, the customer's governance level decides on changes and on whether things are done. This approach works better for runways than for smartphones because feedback cycles are usually relatively slow.

Scope changes: The name says it all, doesn't it? The change request game (correction: change request process) is inten…

Working with Scrum, I have found the metaphor of a “sprint contract” to be helpful in understanding the relationship between Product Owner and Development Team, and for protecting the whole team from outside interference.

A Scrum project can be considered a series of mini-projects. Each project adds additional functionality to the product. This is known as an iterative, incremental approach, and these mini-projects are called sprints.

Like for a project, the parameters time (sprint length), quality (definition of done), cost (team size*sprint length), and scope (sprint goal and forecast) define the sprint. Unlike a classical project, a sprint is relatively short and has always the same length.

Every sprint, the Team delivers something called the “product increment” that could be shipped or deployed: it will work, it will be on time, and it will stay within the budget for the sprint. Because there is uncertainty in how much they can get done, the Team may accomplish more or less than…

Which contract form is the right one for your project? It depends. In this chapter we examine each of the widely used contract forms and evaluate them in the context of the criteria we set out in Chapter 5, What is the purpose of a contract?


The Sprint Contract - Not really a contract, but a useful metaphor to describe the agreement within the Scrum Team during the sprint. Fixed-Price, Fixed-Scope - All the product decisions are taken up front. The winner is the master of the change request game.Time and Materials (T&M)– Risk is owned by the customer. So are the costs.T&M with Fixed Scope and Cost Ceiling – The worst of both worlds from the supplier’s point of view.T&M with Variable Scope & Cost Ceiling – A pragmatic approach to outsourced product development.Phased Development – How venture capitalists work with start-ups.Bonus and Penalty Clauses – Looks good on paper, works better with things you can build out of concrete. Fixed Profit – Share the risk and incentivi…

A contract substitutes for a lack of trust. The more trust exists between customer and supplier, the less you will need to write down.
What do you need to put in a contract?

It can be difficult to trust an organization unless you are dealing with people at the highest levels, because individuals in an organization can be overruled by people higher in the organization.

People come and go, so the people you are dealing with now may not be the same who will be making decisions in the future. And even people at the top of the organization have ups and downs in their power and influence. A contract offers continuity in the face of changes to organization.


Even when working with people you trust and who have the necessary freedom or authority to stand by their word, it can be helpful to write things down. The written word is an excellent tool for recording what two or more people have agreed to.

In my experience, there are seven points which belong in every contract:
Identify the parties…