Commit to Sprint Planning or Definition of Done, Not Both

I'm having trouble with people's use of the term commitment.

In Scrum and other agile processes, the term commitment-based sprint planning is used to indicate that a development team should promise to deliver the set of features as agreed upon in the planning meeting. In fact, the team should try and do everything they can to deliver the features at the end of the sprint.

But what if things go wrong?

What if a team member falls ill? What if there's a 1-day power failure?

What if the technical platform turns out to have bugs the size of Gregor Samsa?

Murphy's Law dictates that there's always something going wrong, in every sprint. Most often the problems are small and neat, but sometimes they are big and smelly. This cannot be prevented. Many people try to estimate the amount of uncertainty per sprint, but the power law in our projects dictates that we cannot estimate the size of trouble. So, whatever the size of the problem, a team simply has to deal with it when it hits them in the face and craps all over their task board.

The team has three choices:

  1. Work more hours to compensate for the setback, and still deliver all features;
  2. Cut corners in quality, which means breaking the Definition of Done;
  3. Skipping some of the features, which means not adhering to the sprint planning.

It appears the team is faced with a small version of the project management triangle, or the triangle of constraints. Which isn't surprising, because a sprint is nothing more than a very small project.

Option 1 conflicts with the Sustainable Pace and 40-Hour Week practices. All available research shows that management and teams should commit themselves to a sustainable pace (which is any amount of hours a team feels comfortable with).

Option 2 conflicts with the goal of delivering a quality product. In a professional agile environment, the Definition of Done should not be ignored, unless the team unanimously agrees to incur technical debt that should be resolved in later sprints.

Option 3 conflicts with commitment-based sprint planning. If you decide it's ok to skip features then you're sending people the message that it's ok to break commitment. And commitment-based sprint planning loses its value.

So, will you break your commitment to the sustainable pace? Or to the Definition of Done? Or to commitment-based sprint planning? Pick one!

If your best option is to break some commitment when things go wrong, then you shouldn't be calling it commitment in the first place!

You are sending the wrong message when you decide to break any commitment. You're showing people that it's ok not to do what you promised. If you break commitment to one of the three options, then people might feel free to break the others too!

Interaction dominated by obligations. These obligations may be mutual, or self-imposed, or explicitly stated, or may not. Distinction is often made between commitment as a member of an organization (such as a sporting team, a religion, or as an employee), and a personal commitment, which is often a pledge or promise to ones' self for personal growth. (Wikipedia)

Don't make promise you may not keep…


There should only be a real commitment for the things that are absolutely essential to make the project survive in a troublesome environment. For some projects (like the one I'm working on now) this means commitment to release a high-quality product some time in the future. This translates to my commitment to the Definition of Done, but I won't commit to individual sprints plannings. For other projects it can mean commitment to release a feature-complete product at a certain deadline, which translates to a team's commitment to delivering certain sprint items, but then they shouldn't commit to the Definition of Done.

And if both are unacceptable to you (when you need commitment to both quality and features), then you must explicitly decide not to commit to a sustainable pace.

Unfortunately, I have no extra-sensory perception. I cannot tell you what you should commit to. It depends on the project, and your decision may change with every sprint.

But I believe that, whether explicitly or implicitly, every week you should choose not to commit to either sustainable pace or the Definition of Done or the sprint planning. You cannot commit to all. And my suggestion would be to choose explicitly at the start of each sprint, and write your decision on your task board! Make the choice together. Communicate your decisions. And prevent any wrong assumptions.

And choose wisely.

(images by littledan77 and discoodoni)

Twitter TwitterRss SubscribeEmail NewsletterDelicious Bookmarks

Latest, greatest and favoritest posts:
About Project Success and Failure
You Are a Gardener (Oh, and Me Too)
How to Annoy Your Boss (14 Real-Life Tips)

Related Posts
free book
“How to Change the World”
  • Jan

    I sometimes wonder how many software-producing organizations still work to deadlines. We (at ) try and release a milestone every 3-4 weeks. After each milestone we agree on a set of must and can features, as well as a tentative release date 3 weeks into the future. We also evaluate whether the release date has external constraints (e.g. commitments to partners, changes in the api etc.) or whether we are somewhat flexible. Mostly, it is the last case.

    Then, when the release date approaches, we see what has been done and what is still open. We then have the option of a) cutting features as you describe or b) postponing the release. Since we only release Tuesday-Thursday, preferably Tuesday, this means either plus 2 days or plus 7 days.

    Being able to postpone the deadline a bit allows us a much more relaxed development than adhering to a strict deadline and cramming everything in.

    Perhaps that could be a third option? Add a bit of flexibility to the deadline. As every business student is taught, there is value in flexibility…

  • Jacob

    Another characteristically insightful post. Good job clearly identifying and explaning a common but often overlooked triangle of constraints.

  • Dale

    This is where the concept of “try” shows its value. Despite Yoda’s warning, there is such a thing as try and it’s a valuable thing. Commit to trying.

  • Josh Nankivel

    Great post, this is an important topic. On my project, the time constraints are real because the software development pieces are not happening in a vacuum; there are direct dependencies at play which mean if we are late with a release, we might not make our launch window. When the satellite launches, certain things have to be done, period.
    Here’s another option if you have a longer time line than a single sprint: add more people. Small blips are one thing, but if you uncover some information that changes the ball game enough, it can make sense to go get a few hours from a developer or engineer elsewhere to help the team out.
    Josh Nankivel

  • Francis Martens

    Hard commits are not only necessary externally to downstream organizations (QA, Support, …) but also internally towards the other team members.
    A hard commit has two aspects,
    1) Focus
    It helps all the members of the team to focus to what has been promised
    2) Measurement
    It helps the team to gauge their future commits.
    Short sprints help them remember their state of mind when they made their previous commit.
    A commit is in the first place a motivational tool for the team. Failure to commit is one of the five dysfunctions of a team, and committing to a result must be part of any serious methodology (called scrum, kanban, lean, waterfall, whatever).
    In case of failure to meet what has been committed should be addressed during the retrospective/lessons learned …

  • Andy Roberts

    Isn’t there a fourth option ? De-scope a little while still satisfying the sprint goal ? The de-scoping would need to be negotiated with the Product Owner of course, and this does assume you have a sprint which is homogeneous enough to be summed up in a sprint goal. The de-scoping could be either dropping/relaxing acceptance criteria or else dropping whole user stories.

  • Jurgen Appelo

    Agreed. But commitment to trying would be crucially different from commitment to doing. I wonder how many teams understand the difference.

  • Jurgen Appelo

    Adding more people during a sprint is usually not an option in Scrum projects. Not only because of logistics (where do you get extra people to start the very next day?) but also because Scrum says teams size shouldn’t change in sprints.

  • Jurgen Appelo

    Isn’t descoping the same as cutting features?
    It doesn’t matter whether you’re cutting depth or width out of the feature set. You’re cutting into functionality, which is the same as option 3, I believe.

  • Andy Roberts

    You may be cutting features, yes, if you drop whole stories. I think that’s less likely, though, if you’re merely cutting some acceptance criteria.
    What I was trying to draw attention to, though, was the idea of have a higher level goal (the ‘sprint goal’) that that implied by all the detail derived from Sprint planning. If the team commits to the sprint goal, then it can still (with a bit of negotiation with the PO) feel it’s been relatively successful in the sprint even though some scope has been trimmed.
    And, who knows, maybe it will turn out they need to deal with the trimmed scope next sprint, or maybe the product owner will defer it in favour of more important work, when he/she next assess priorities.

  • Rachel Silber

    I think the best tactic is to undercommit. There should be a margin of safety in the plan, if sustainable pace is to be, ever, actually sustainable. It’s better to add more stories if possible, later in the iteration.

  • Chris

    As you point out, Option 1 should be non-negotiable in most sprints.
    And once you know about DoD, Option 2 isn’t really an option, either. That is, you’d have to explicitly decide: we’re going to leave it up to each team member to decide when a work item can be checked off the Sprint Backlog.
    That leaves Option 3, which is in fact how Scrum rules work. It’s the Scrum Master’s responsibility to ensure that the team and the Product Owner all understand that the plan is just that: a plan, not reality…that sustainable pace and DoD come first. And that small negotiations may be made if suggested by the team and accepted by the PO, and that both management and the team have the power to terminate the sprint early in the off chance that the power law throws a tsunami at you.
    I think we’re agreed so far, which just leaves a bit of semantics around the word, “commitment.” If you believe it’s possible to make a prediction about a complex system with 0% chance of being proved wrong, then your definition of commitment works.
    I’d say that commitment is an agreement to act toward an agreed-upon goal, whether or not the goal is achieved. You agree, for example, not to endanger this sprint’s goals by working on items further down in the Product Backlog. You agree to limit your work hours in order to avoid the risks of exhaustion. You agree to keep a work item open until all DoD criteria have been met.
    (Off topic, this has me thinking about commitment in marriage. With our near-century long lifespans, perhaps it’s time we considered sprint-based marriages.Sprint 1: 5 years, or until a conception is desired by either party. Sprint 2: 18 years, contingent on the child’s survival, extended automatically with the birth of subsequent children. Etc. Sick? Maybe.)

  • Bill Wake

    You left out two options that I see Scrum providing:
    4. Commit to a sprint goal, not a set of stories
    One of the earlier comments touched on this.
    (And it’s not like it should be a surprise to the product owner on the last day:)
    5. Sprint cancellation
    If a team realizes it can’t do what it committed to do, they need to raise the flag then. People rely on you, & if you’re going to fall short, they need enough advance notice that they can either switch approaches, get more resources, cancel the project, etc.
    I see commitment not as an impossible guarantee made in a hostile universe, but as a promise that you believe you can do it, you’re trying to do it, you’ll provide warning if it’s at risk, and if you fail you’ll take your lumps.

  • BF

    I think the subject here is very abstract and in the real life things can go very well even if people select all of the 3 goals mentioned above (quality, scope and date). Because, working in iterations means just that: Reducing risks to an acceptable level. To reach commitments you should always improve quality, and always put a buffer into the process.

How to Change the World - free Workout - free