Peter Stevens’ Scrum Breakfast Blog

Home / Peter Stevens’ Scrum Breakfast Blog
Peter Stevens, Entrepreneur and Scrum Trainer

Scrum Breakfast

Blog about Scrum: Getting started, Crisis Project Management, and Transforming IT into a Lean Organization.

Ten contracts for your next Agile project

Posted on June 20, 2019, 8:26 am
As a customer or supplier of software services at the beginning of an Agile software development project, you know that there is too much at stake to work with just a verbal agreement. Although the Agile Manifesto values customer collaboration above contracts, written contracts are often necessary when working with external suppliers. What do you need to know? How can the contract help you achieve a good result? What are the traps to avoid?
Kevin Smith CC-BY
Contract Cloud courtesy of Kevin Smith

Ten years ago, I wrote an article for called Ten Contracts for Your Next Agile Project. Artem Marchenko, the founder and editor, was really enthusiastic about this article and pushed me to make it thorough, well-researched and well-documented. This article became a popular reference. I was invited to speak about the ten contract forms at the Munich Scrum Gathering in October 2009. And I was thrilled to see the search autocomplete suggest the title after typing just “10 contracts.”

Alas, ASD is no more, but various people have requested that I republish the article. Last fall I started working on an update. I got it “90% finished” but never quite got around to publishing it.

A few days ago, while attending Jacopo Romei’s meetup on “Extreme Contracting”, I was surprised to see some of my original language and risk/reward diagrams reproduced in his presentation – with attribution to someone else! It’s clear: The topics in this book are still relevant!

I went on the Internet and discovered that the original article and presentation are hard to find and many of the reproductions are without attribution. So enough procrastination, it is time to republish!

I have learned a lot about Agility in the last ten years. The community has advanced a lot in this time. So, an update is more than necessary.

One caution: IANAL. I am not a lawyer. The advice in the following pages is based on my experience as a consultant, trainer and entrepreneur. If you need advice, get the advice you need. It may seem expensive, but good advice can be much cheaper than no advice!

I have expanded the original two articles into a 58 page-book which should serve as a lightweight guide for your next Agile software project! 

You can get the whole book now, or you can read it a chapter at a time as I publish it here under under the label ten contracts. As I publish the chapters (scheduled for a period of three weeks), I will activate the links below.

Ten contracts for your next Agile project, by Peter Stevens
Table of contents

7.8. Fixed-Profit

You can download the e-book or pre-order the physical book at

Read on the blog

What are they talking about? A glossary of Scrum and Agile terminology

Posted on June 20, 2019, 6:00 am
What are they talking about? What is the difference between acceptance criteria and the definition of done? Every field has its own special vocabulary and agile software development is no exception.
Artwork courtesy of Laura Quattri. Used by Permission
From acceptance criteria to working agreements, the following guide will help you navigate the waters by understanding the terminology.
  • Acceptance criteria - tests which must be passed for the Product Owner or customer to consider the story accepted. The Team should verify these before submitting a story for final approval. Acceptance tests help ensure external quality. Most product backlog items can be mapped to one or more acceptance criteria. See Definition of Done and Quality, external.
  • Agile - a movement for finding better ways of developing software. Scrum and Extreme Programming are two leading examples. Others, such as Kanban or Lean Startup do not define themselves in the agile tradition but are based on compatible values and principles.
  • Agreement - the basis for planning and completing work in Scrum. Examples: the definition of done, the selected product backlog, the sprint contract, and the definition of ready.
  • Artifact - something that archaeologists find when digging. Often used to describe the documents produced by a project management methodology. Scrum artifacts are all living documents to guide and monitor work. In Personal Agility they are called “tools.”
  • Backlog Refinement - the process of getting backlog items ready for implementation in the sprint. Typically, this means taking large, poorly defined backlog items, discussing them, and replacing them with several “smaller” backlog items that are individually less complex and easier-to-implement, but still add up to the original whole.
  • Best practice - some consultant's solution to someone else's problem. Is your context similar enough to the original for the solution to be applicable to you? Questionable. Will you do better by coming up with you own solution? Usually.
  • Ceremony - a fancy word for a meeting or routine process. In Scrum and Personal Agility these are called “events” to signify that something important happens and you want and need to be there!
  • Chickens - deprecated term for people interested in the results of a project, but not 100% committed to its success (e.g. due to conflicting priorities). Chickens can be very disruptive to the team. Never call someone a chicken. Spectators is a better metaphor. A professional sports game is played for the spectators, but the spectators are not allowed to interfere with the game.
  • Commitment - a core value of Scrum which should not be interpreted to mean that the team is expected to burn itself out trying to achieve unrealistic goals sprint after sprint after sprint.
  • Daily Scrum - a daily opportunity for the team to inspect and adapt on their progress throughout the sprint. Three traditional questions help the Team recognize that they need to talk to each other (preferably right after the daily scrum).
  • Definition of Done - an agreement on what 'this backlog item is done' actually means. Helps assure internal and external quality for each story. Often expressed as a checklist to be completed before submitting the story to the Product Owner. The definition of done applies to individual backlog items and to each increment, but not to individual tasks or whether the overall release has enough functionality to be delivered to the customer.
  • Development Team - consists of 3 to 9 people who have all the skills necessary to get from “idea” to “done” (not from spec to ready-to-test). Often referred to simply as “the Team.” The Team (and only the Team) creates the solution. It is responsible for “How?”. The Team is protected from noise but not isolated from the organization.
  • Done (for a feature) - a binary state. Either a backlog item is completed according to the definition of done, or not.
  • Done (for a product) - a judgement call by the Product Owner. At the end of a sprint, if the Product Owner believes that it's worthwhile to release, the product should be releasable. If it's not, there is undone work which should be addressed at the level of the definition of done in future sprints.
  • Estimate - the team's best guess at the size, complexity or time involved to convert a PBI into a piece of finished functionality. An estimate is not a commitment. More time on backlog refinement is usually more helpful to performance than more time on estimation.
  • Extreme programming (XP) - an agile approach to software development, often applied in conjunction with Scrum. XP defines the engineering practices needed to produce quality software in an iterative environment.
  • Evil - something which is difficult or impossible to get rid of but avoiding it is generally good for you. Weeds in the garden is one example. Treating multitasking, bugs, dependencies and spillover as evil is usually good for team performance.
  • Forecast - the Team's best guess at how much finished functionality it can deliver by the end of a sprint. The Team is normally expected to respect all the terms of the sprint contract, i.e. quality, time and cost, which are more important than scope.
  • How-to-demo - a short workflow for demonstrating to the Product Owner that the functionality has been implemented correctly. Also, useful to limit scope creep while implementing a product backlog item (“story”).
  • Impediment - anything which slows the Team down or prevents someone from working. Although the Scrum Master is charged with removing impediments and all Scrum events provide regular opportunities to recognize them, impediments can be identified and eliminated at any time by anyone.
  • Increment - an additional slice of customer visible value delivered at least once per sprint. The latest increment must integrate with the previous delivered increments to form a working whole.
  • Multitasking - pretending you can do more than one thing concurrently. In theory, if there is unused capacity available, multitasking can improve performance. However, multitasking has a cost, and if there is no free capacity it lowers performance by introducing wait times and creating dependencies between otherwise independent processes. Usually focusing on getting one thing done at a time is better for performance.
  • Must - absolutely required, or else! The Product Owner must attend sprint planning 1, otherwise the meeting cannot be held.
  • PBI - Product Backlog Item.
  • Pigs - deprecated term for those people 100% committed to the project at hand. Always refers to Scrum Master and Development Team. If it does not also refer to the Product Owner, this is a sign of dysfunction. While it might be okay to call yourself a pig, “players on the field in a professional sports match” is a better metaphor. Yes, the game is played for the spectators, and the spectators can have a surprising influence on the result, but the players must be able to play without undue interference. See also Chickens.
  • Priority, sequence - which item comes first, second, third, etc. The term priority is deprecated in Scrum because a) it contains emotional overtones and b) two items could have the same priority but in Scrum they must have a unique place in line, that is, in the product backlog.
  • Product Backlog - the single source of requirements for the product under development. It consists of functional and non-functional requirements. It is not used to plan work or define intermediate artifacts, like a specification, which have no value for the customer or user.
  • Product Backlog Item (PBI) - an entry in the product backlog consisting of a description (often a user story), a sequence position, and an estimate. Often enriched with acceptance criteria and other useful information. A PBI is not a specification, but rather a reminder to hold a conversation shortly before implementation.
  • Product Owner - a servant leader who guides the Development Team to produce customer visible value. Sometimes called the voice of the customer (or user) or the organization’s ambassador into the Scrum Team, the role represents all interests outside the Development Team to the team.
  • Quality, external - Did you build the right thing? Does it perform the way the customer or user wants and expects? Acceptance tests strive to ensure external quality.
  • Quality, internal - Did you build it right? Does the product behave the way its creators intended? Unit tests ensure that a program continues to behave correctly, even after modifications have been made.
  • Quality, overall - Are there enough features present to justify delivery? Also known as 'fitness for use.' A state achieved incrementally in Scrum. The Product Owner decides when this has occurred by calling for a release.
  • Release burn-down chart - a tool for visualizing the progress of the team toward a medium-term release goal. The x-axis represents time, measured in sprints. The y-axis is the sum of the estimates in the product backlog. When a PBI is done, its estimate can be deducted from the burn-down chart. It is the primary tool for ensuring that wishes and probable reality stay reasonably aligned.
  • Release burn-up chart - serves the same purpose as a release burn-down chart with a different visual representation. The y-axis represents the cumulative sum of the estimates of the features that have been included in the product increment.  When a feature is completed, it’s estimate is added to the burn-up chart.
  • Release Planning Meeting - the Scrum Team comes together to refine the product backlog to focus on creating a release. Although time-boxed, there is no decision to be taken at the end of the meeting, so it is often a useful preparation for sprint planning. This term is deprecated, replaced by backlog refinement, which leaves more space for creative thinking.
  • Retrospective - the Development Team (and anybody they invite) reflects on how they worked to identify improvements for the next sprint. Usually the Scrum Master is invited to facilitate.
  • Ritual - fancy word for a meeting or routine process. Kind of implies that you won't miss anything if you don't go. Call it an event or an activity instead.
  • Scrum - a simple, team-based approach to solving complex problems. A mindset based on a culture of transparency and regular cycles of inspection and adaption. A popular approach for developing software.
  • Scrum Master - a servant leader who helps Product Owner and Development Team perform better. Helps the rest of the organization recognize which interactions with the Scrum Team are helpful and which are not. Encourages doing more of what’s helpful and less of what isn’t. Coaches and facilitates. Removes impediments. Sometimes called a change agent, the Team’s ambassador to the organization, or voice of common sense.
  • Scrum Team - all three roles together make up the Scrum Team. Sometimes called the whole team.
  • Selected Product Backlog - deprecated term for the subset of (by definition top priority) product backlog items that the Team reasonably believes it can complete during the sprint (often mistakenly called the sprint backlog). Today this is called the forecast.
  • Sequence - a unique ordering. First, second, third... The product backlog is sequenced.
  • Should - highly recommended. The Scrum Master should be present at the daily scrum. This is much stronger than optional. However, no activity in Scrum is cancelled due to the absence of the Scrum Master. See also Must.
  • Spillover - work that has been started but not completed by the end of the sprint. Contrary to popular belief, spillover does not automatically carry over into the next sprint. Excessive spillover is typically a symptom of over-commitment in sprint planning and/or multitasking in the team. Technical debt is a subtle form of spillover.
  • Sprint - a time-boxed period for completing work. A sprint consists of planning, doing and review, both of the results and of how the team worked. Maximum time-box is 30 days. 2 weeks is common. All forecast work should be done by the end of the sprint.
  • Sprint Backlog - the selected product backlog, enriched with a technical concept and a task planning. The Sprint backlog represents the team's concept for achieving the goal set during the first half of sprint planning. The plan is updated daily by the Team.
  • Sprint Contract - the agreement between Product Owner and Team at the beginning of a sprint: time (sprint duration), cost (team composition), quality (definition of done) and scope (selected product backlog). If the team should fail to deliver on any aspect, it should fail on scope.
  • Sprint Planning - addresses two questions: what and how. The meeting is divided in two halves, sometimes referred to as sprint planning 1 and sprint planning 2 for addressing these questions. While the Scrum Guide considers this to be one activity, many practitioners consider each half to be a separate event with its own time-box.
  • Sprint Planning 1 (SP1) - the Product Owner and the Development Team agree on what will be developed during this sprint. The Product Owner defines priorities, the Team estimates how much is doable. Both parties influence the final agreement: the forecast and the sprint goal.
  • Sprint Planning 2 (SP2) - the Development Team decides how to solve the problem accepted in SP1. The result is a technical concept and a task planning, often in the form of a task board.
  • Sprint Review - the Scrum Team meets with users and stakeholders to inspect and adapt the product, based on done functionality. They will review what has and has not been completed and reflect on how to change the product backlog before the next sprint planning. This event is for getting feedback about the product from the stakeholders, not for evaluating the team’s performance or whether individual backlog items are done.
  • Stoos - a movement for finding better ways of managing organizations, named for the gathering that took place in Stoos, Switzerland in 2012. Inspired by the agile movement, Stoos seeks to catalyze a lasting change in how businesses do business.
  • Story - term often used to refer to a product backlog item, even if not formulated as a user story. Can also refer to a medium sized backlog item (on the scale of epic >> story >> grain of sand).
  • Story Point (SP) - a widely used, though not universally used unit to gauge the size of a PBI relative to other PBIs, estimate the size of a project and monitor progress. Something like a kilometer for code, so you can use the math of distance, rate and time to monitor progress and estimate completion.
  • Task - the Team uses tasks to plan the work in the sprint. When all tasks associated with a story are completed, the story should be done. Typically, a task represents a goal for the day, or something smaller. Most coaches no longer recommend estimating tasks in hours.
  • Task Board - a visual representation of the work to be completed in the sprint. Typically, 4 columns, organized in swim lanes, per story: story, tasks waiting, tasks in progress, tasks done. Often supplemented with burn-down charts, impediments and other useful information. The task board belongs to the Development Team, not the Scrum Master, Product Owner or outside managers.
  • TDD Test Driven Development - also known as red-green-refactor. 1) write a failing unit test (red) 2) code a first draft to turn the test green, keeping all other tests green) 3) "refactor" to create an improved and final draft. TDD improves productivity by reducing misunderstood requirements, rework, and escaped errors.
  • Team - an older term for the Development Team. Because effective collaboration between Product Owner and Development Team is associated with high performance, Product Owner, Scrum Master and Development Team are now referred to as the "Scrum Team".
  • Technical debt - a consequence of poor engineering practices which make a program difficult to modify. Like financial debt, technical debt must be paid off or technical bankruptcy follows: throw the program away and write a new one.
  • Time-box - a constraint to prevent a complex situation from degenerating into chaos. All events in Scrum are time-boxed.
  • Undone work - can you release the product at the end of the sprint? If not, there is undone work. Typical examples include regression testing, usability testing, customer acceptance tests. The less undone work you have, the more predictable your release dates. See Spillover.
  • Unit tests - automated tests written by the Development Team to assure internal quality. Unit tests enable refactoring and provide an essential safety net, so that changes and fixes do not introduce new errors.
  • User story - a people-centered approach to defining requirements with a standardized form: as <some role or persona> i want <some value> so that I can achieve <some goal or purpose>. The word 'user' should never appear in a user story.
  • Velocity - a unit to gauge the speed of development and estimate the completion date of large projects. Usually expressed as story points per sprint.
  • WAP - widely adopted practice, often used together with Scrum, but not part of Scrum—you may do it or not if you feel it applies to you. Examples include story points, user stories, definition of ready.
  • Whole team - an XP term for the Scrum Team.
  • Work in progress, WIP - work that has started but has not yet been completed. Lots of WIP is associated with poor performance and inability to get things done. See Spillover.
  • Working agreement - an agreement among interested parties to enable more effective work. Working agreements are the basis for improvement in Scrum.

Read on the blog

Recommendations for an Agile contract

Posted on June 19, 2019, 6:15 am
A contract manages some risks but not all of them. More importantly, the contract defines the playing rules, which in turn drive people's behavior.  What would you like to have in a contract? Conditions that encourage behaviors that lead to project success.

The following thoughts are based on my own experience working both as a supplier and as a customer of external development services.

Artwork courtesy of Laura Quattri. Used by Permission

Good Product Ownership is Essential

An effective Product Owner can dramatically reduce the risk of a project and increase your chances of success with your new product. A Product Owner is a decision-maker, so this almost always means the Product Owner has to work for the customer, not the supplier.

If you are contracting with an external supplier for software development, Scrum is a good choice for managing the process, if – and this is a big if – the customer supplies an effective Product Owner who engages and collaborates with the rest of the Scrum Team.

Learn to be a good Product Owner. Product Owner classes teach you how to manage the backlog, how to formulate and refine requirements, how to define and refine acceptance criteria, how to reduce the risk of the project, how to work with the team in the before, during and after each sprint. In short, it gives you the skills you need to lead a development project.

Each Development Team's First Milestone

The first goal is to deliver reliably every sprint. If the Team can produce something that works and could be shipped every sprint, most risks go away. It is not about how much they deliver. It is about delivering in production quality something that could be shipped. It might take the Team a few sprints to be able to do this reliably, because it is not easy. This objective might be something you want to define in the contract.

Fixed-Price is easy to achieve, if...

I have worked quite happily for years with a phased development contract. The original contract was a fixed scope contract with cost ceiling, but as we worked together and built up the level of trust, the surrounding text just withered away. Trust, a bit of boilerplate, the sprint contract and a quarterly sign-off from top management worked quite nicely.

If the team can deliver reliably every sprint, and given that the cost per sprint is fixed, then you can predict both your release dates and the total cost months in advance. The scope is defined on route, so you don't know "exactly" what you are going to get. Too much pressure to deliver in a short time frame is usually counterproductive.

How to get the right scope quickly

“Money for nothing, changes for free” contracts can turn the advantages of the Scrum and Agile development processes into a competitive advantage.

By prioritizing and delivering business value incrementally, the chances of an outright failure are dramatically reduced. This advantage is passed on to the customer.

Furthermore, it’s a cooperative model, so it offers incentives to both parties to keep the costs down.
The early cancellation clause rewards the higher productivity achieved with Scrum teams. On the down side, this clause feels a bit like a 'golden parachute' which may not be politically acceptable.

This contract might work with a cost ceiling although I would be wary of losing the cooperative relationship.

The contract form lays the important groundwork for a successful project. And the Agile Manifesto got it right: working with the customer is more important than the contract. Whatever you do, keep the customer relationship positive!

Should you condition payment on the results of individual sprints?

Should you pay the supplier more if the Team delivers more? And less if they deliver less? In general, I don't recommend it.

This approach encourages valuing quantity over quality. It encourages the Team to settle at a ,performance level that they can comfortably achieve. And if the Team does have a sprint that doesn’t produce any working functionality as a result, they may not be able to withstand the economic hardship it produces, especially if the loss is passed on to the individual members.

Suggestions for a Scrum Contract

Scrum is modeled on successful patterns of product development. Based on my experience working on both sides of the agreement, I would suggest addressing the following points to ensure that Scrum works as intended:


Define the purpose and goals of the project, leave the details to the “sprint contract.”

Respect for the Sprint Contract: Unless the Product Owner exercises their authority to cancel a sprint, no changes to the goal or team composition during the sprint without agreement among all members of the Scrum Team.


Product Owner, Scrum Master, and Development Team (collectively the “Scrum Team”) as defined by the Scrum Guide. Define who will serve in each role.

Product Owner: Provided by the customer. Having the supplier provide the Product Owner (“because no one on the customer side has the time or knowledge”) is extremely dysfunctional. Only the customer has decision-making authority.

Ensure the Product Owner’s authority as a decision maker in the project, including having the final say whether something is done and accepted; confirm that they have enough capacity to support the team; and are able to perform regular, extended visits to the supplier’s site. Extensive face to face collaboration between the Product Owner and the offshore Development Team is a success pattern.

Development Team Members: Provided by the supplier. The Development Team needs all the skills necessary to create a finished increment (a “feature team”) and does not take instructions from anybody but the Product Owner through the sprint planning process.

Scrum Master: Provided by the supplier. Having the customer provide the Scrum Master (“to maintain control”) is extremely dysfunctional. Who would protect the Development Team from an overzealous Product Owner or ensure that the Customer fulfills their responsibilities?

Chief Impediment Removal Officer: This role, which is not a role that Scrum defines, represents an independent communication channel between the Scrum Master and the customer. This person takes responsibility for resolving impediments that cannot be addressed by the Product Owner or the Scrum Master alone.

This is not about escalation. This is about ensuring that impediments get addressed and to prevent actual escalations.


Sprint Reviews: Occur once per sprint and are attended by the Scrum Team and the stakeholders. It may be desirable to name key stakeholders who must also be present.

Deliverables: At least once per sprint, a potentially shippable product increment must be produced by the Team and made available to the customer. Nothing may be included in the product increment unless it is done according to the definition of done as defined by the Scrum Team.

Spending authorization: How much money may be spent over what period of time?

Termination: What to do if the team achieves a viable product before the budget is exhausted. What to do if the customer wishes to cancel or prolong the project. How much notice is required to cancel the development work?

You can get the whole book now, or you can read it a chapter at a time as I publish it here under the label ten contracts. To download the e-book or pre-order the physical book visit

Read on the blog

The 10 contracts for your next Agile software project

Posted on June 18, 2019, 8:47 am
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?

Photo courtesy of hydropeek@flickr CC-BY-2.0

  1. The Sprint Contract - Not really a contract, but a useful metaphor to describe the agreement within the Scrum Team during the sprint.
  2. Fixed-Price, Fixed-Scope - All the product decisions are taken up front. The winner is the master of the change request game.
  3. Time and Materials (T&M) – Risk is owned by the customer. So are the costs.
  4. T&M with Fixed Scope and Cost Ceiling – The worst of both worlds from the supplier’s point of view.
  5. T&M with Variable Scope & Cost Ceiling – A pragmatic approach to outsourced product development.
  6. Phased Development – How venture capitalists work with start-ups.
  7. Bonus and Penalty Clauses – Looks good on paper, works better with things you can build out of concrete. 
  8. Fixed Profit – Share the risk and incentivizes both parties to come to a conclusion.
  9. Money for Nothing, Changes for Free” – Encourages both customer and supplier to focus on value.
  10. Joint Ventures – A marriage made in heaven…? Or hell?!

The text is excerpted from Ten Contracts For Your Next Agile Project, by Peter Stevens. 
You can get the whole book now, or you can read it a chapter at a time as I publish it here under the label ten contracts. To download the e-book or pre-order the physical book visit

Read on the blog

Joint Ventures

Posted on June 17, 2019, 6:00 am
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?
Photo Courtesy of AFGE – CC-BY-2.0

Desired Benefit

Join forces to achieve a goal that neither party could achieve alone without defining a hierarchy between the partners.


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.


Defined to suit the needs of the partnership.


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?


Treat the joint venture as a separate entity: One team, co-located, with development and product marketing/product owner role. Think realistically about friendly and not so friendly separation scenarios.

You can get the whole book now, or you can read it a chapter at a time as I publish it here under the label ten contracts. To download the e-book or pre-order the physical book visit
Read on the blog