Commit to Sprint Planning or Definition of Done, Not Both

24 July 2009

Posted in Risk & Uncertainty

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:

Work more hours to compensate for the setback, and still deliver all features;
Cut corners in quality, which means breaking the Definition of Done;
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!

Commitment
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 – Subscribe – Newsletter – Bookmarks