Commitment Driven Planning

During the sprint planning meeting, most Scrum teams use velocity in some form to determine how many stories they can take that sprint. However, there is an alternative approach to planning outlined in Mike Cohn’s Agile Estimating and Planning that I prefer, Commitment Driven Planning.

WARNING: The following post talks about “commitments” and “planning” if your agile worldview finds these terms dangerous and unsafe, continue at your own risk.

What is Commitment Driven Planning?

Commitment Driven Planning (sometimes called Capacity Driven Planning) is a technique that lets a team determine how much work to bring into the sprint based on how much time they have to do said work.

What do I need for Commitment Driven Planning?

In order to get started with commitment driven planning, you only need a few things:
  1. The total capacity of the team in hours*
  2. The ability to estimate how many hours* a story will take to complete
  3. A facilitator
* You could substitute hours for another measurement of time, but I’ve found that hours are ideal

Commitment Driven Planning in 5 Steps

  1. Add up the capacity of all team members to arrive at a total capacity
  2. Discuss each story as you would normally, defining done, exploring scenarios etc.
  3. Task out the story and add up the hours for each task
  4. The facilitator asks the team “Do you have enough capacity to commit to this story?”
    1. If the answer is “Yes” the team adds the story to their commitment
    2. If the answer is “No” the team moves on to another story, or breaks down the current story.
  5. Repeat the process for the next story.

Calculating Total Capacity

Total capacity for the team should be calculated by adding up the total capacity for each team member. Capacity for each team member should factor in vacations, meetings, personal days and any other time that individual knows they will not be spending with the team working on the commitment. You should avoid using ideal numbers for individual capacity and stick to the elephant in the room numbers. For example, rather than assuming everyone will be working 8 hours in a day, use 6 hours when it’s common to arrive at 9AM, take an hour for lunch and leave at 4:30. This can be challenging as it often exposes the realities of how the team works, but it’s much easier than dealing with the pain later.

Task Out Each Story

For many teams, this is the most difficult step of Commitment Driven Planning. A lot of teams that are trying a Commitment Driven approach for the first time expend a lot of energy worrying about getting their estimates “right”. While getting estimates “right” is beyond the scope of this post, I will say that if you just focus on making sure you have all of the known tasks required to get the story to “DONE” you will probably be okay.

Can We Commit to This Story?

This is the most important step in the commitment driven process. It is vital that the team be able to decide to what level they fill their capacity. If the team thinks that given all the known circumstances they can only fill 50% of their total capacity, that’s okay, but more on this later. If you are one of the brave anti-commitment agilists who made it this far, I hope I am easing your fears of stick bearing managers beating the team in the name of commitment.

Committing to 50% and Buffer Time

Earlier I mentioned that it would be okay for a team to only commit to 50% of their capacity. This, like many things in agile, is a two way street. If the team commits to 50% of their capacity, they should be expected to finish in 50% of the time allotted. This presents a very powerful opportunity for being open and transparent with the work and the progress towards finishing that work.

When a team commits to 50% of their capacity in a one-week sprint, we should be able to track that they will be done sometime in the middle of the week. As work begins, discussions at standup about being on track and plans to stay or get back on track should be happening.

It is also very common for teams to want to include a “Buffer”, usually a fixed percentage of capacity. While I’m don’t necessarily believe in 100% utilization, I don’t think that uncoordinated free time (let’s call a duck a duck) is a great approach. I have yet to see a team include a buffer in their capacity that isn’t related to some other underlying, usually larger, problem. For example:
Objection: “We need a buffer because we deal with a lot of interruptions”
You have a problem with interruptions, deal with that.
Objection: “We need a buffer because some people on the team are slower than others”
Embrace collective code ownership, start pairing and improve the skills of the team.
Objection: “We don’t really know what it’s going to take to finish this story”
Improve your definition of “DONE” and remember that you can always inspect and adapt.

Interpreting Outcomes

When you first try a Commitment Driven approach, there is a good chance that you will wildly over or under commit. Here are some common problems and some suggested next steps.
We committed to our full capacity but failed miserably, only completing 1/3 of the work.
Next step: Start to identify where the time went. Were there interruptions? More meetings that expected? Sick team members?
Our task estimates were all wrong and we had to add a bunch of new tasks to every story!
Next step: What questions did you miss at planning that could have helped uncover these “unknowns”? Did certain types of tasks take much longer than expected? Did certain types of tasks take less than expected?
We only committed to 60% of our capacity, but still barely finished by the end of the sprint.
Next step: Did the overall work just take longer? How did the work progress during the sprint? Were there times when no progress towards the commitment was made? Was the progress towards the commitment discussed each day at the standup?

 

 

Retrospective: Setting Expectations

Use this retrospective exercise when you want to help a team set expectations, practice empathy and generate working agreements that move the team forward.

Expectations

Setup

For this retrospective you’ll need sharpies, post-it notes and a wall, window or whiteboard on which they can be stuck.

Setting Expectations

At the heart of this retrospective exercise is defining expectations for yourself and your teammates. Start by explaining that on most teams, there are varying expectations. Some people expect different things from different people and from different roles. The exercise as described below is focused on a Scrum team, but the questions could be adapted for any team.

Ask the team to describe their expectations of the Scrum Master

  1. Be clear that these are not personal expectations of the particular team member who is currently in that role, but the expectations you would have of any Scrum Master on your team.
  2. Ask the participants to write down 3 to 5 ideas, each on separate notes, that describe what they expect of the Scrum Master. (Adjust the minimums and maximums for your group)
  3. Have the participants put their stickies on the wall or board in one big group

Repeat this process for the Product Owner role and the Development Team

Group Ideas

Now that some ideas have been generated, move the participants towards gaining insight by grouping them in like categories.
  1. Using Mute Mapping, have the participants group the stickies, while keeping them in their Scrum Master, Product Owner and Development Team boxes.
  2. With the help of the participants, name each grouping.

Generate Insights, Investigate Assumptions and Practice Empathy

Move through each role and explore the ideas generated by the team. Share that you hope to create a working agreement after discussing these ideas. Some questions might include:
  • Ask someone who is in a different role what might make it difficult for the Scrum Master (or Product Owner or Development Team) to live up to the expectations on the board.
  • Ask if anyone might change their behavior based on what they now know other people expect of them
  • Ask the participants if the expectations listed for a role seem too easy, too hard or just right
  • Ask if anyone is surprised by anything or if there is an expectation that they think is unrealistic
  • Ask if anyone feels strongly about a certain expectation

Create a Working Agreement

Now that the team has a more clear picture of expectations and they have thought about the difficulties of other people in other roles, work with the team to generate a working agreement. Some possibilities include:
  • No Excuses – We refuse to accept excuses when things go wrong
  • Be Brave – We will declare our intent when communicating by declaring “I’m going to be brave…”
  • Core Hours – Everyone will be physically present in the team room for at least 6 hours between 9AM and 5PM
 

Add Some Fun to Your Scrum Board

Physical Boards Please

I recently started working with a team who had been introduced to scrum as part of their organization’s adoption of agile. Their only experience with scrum was through the lens of a popular agile project management tool that rhymes with alley, as in “After using this software I want to vomit in an alley”. When they had the chance to use a physical board, they jumped on it. I setup a very simple scrum board on the outside of a cubicle near the team. We used index cards and colored pushpins, the normal stuff. After a few days, the team was loving it. They enjoyed moving tasks around, pushing green pins into completed cards and keeping an eye on which tasks were in-progress.

Accidental WIP

That’s when I noticed something strange. When I setup the board, out of sheer laziness on my part (I kept pricking my finger reaching into the bag of push pins) I only provided them with three yellow pins and three red pins, one for each member of the team. In doing so, I had created this artificial WIP limit. The team treated the yellow and red pins as their “own” as in, “this is my yellow pin”. At first I just though this was a neat little side effect of the circumstances, but then I realized I could capitalize on the situation by adding some personality to the board.

The last time you played Monopoly™, the board game, did anyone make a big deal about choosing their token? I bet they did, that seems to happen every time I play. There’s always the guy who has to be the race car or the top hat or whatever. People are serious about their monopoly pieces.

So back to the scrum board. I wondered to myself, could I somehow affix monopoly pieces to these push pins? With a quick trip to eBay for a bag of random monopoly pieces and some super glue, I had the answer. Yes, it can be done.

I presented the idea to the team and let them know that if they wanted to use a special push pin they could, or if they’d like to use a regular one that was fine too. The initial reaction was all smiles, quickly followed by, “I’m gonna go first before anyone else picks the race car!”

Probability, Velocity and Re-Estimating User Stories

When working with user stories, story points and SCRUM, it is not uncommon to come to the end of a sprint and realize that a smaller story took longer to complete than a larger story. While this is an excellent reminder that story points reflect complexity, not effort, it is often misinterpreted as an indication that remaining stories need to be re-estimated. Basic probability distribution shows us that over a large enough sample, all three point stories in the product backlog will take about the same time to complete. A team’s desire to re-estimate stories in the product backlog based on a few stories deviating from the norm is a mistake.

Not All Stories are Created Equal

If you were to roll a pair of dice a million times, you would see the majority rolls sum up to seven. If you graphed the data, you would see a bell curve shape. User stories are no different.

Over a large enough sample, you will start to see the same bell curve shape in the time it took to complete those stories. Some three point stories might take two hours to complete while others take twelve; but most take seven. At the same time, some of your five point stories will take ten hours to complete and some twenty four; but most take eighteen. Consider the overlap in the following diagram:

The overlap between the time to complete some of the three point stories and some of the five point stories should not be mistaken for a need to re-estimate any stories. Sometimes a three point story will take as long to complete as a five point story.

Commitment Driven Planning

One technique from which all SCRUM teams could benefit is that of Commitment Driven Planning. From Cohn’s Agile Estimating and Planning

A commitment-driven approach is an alternative way to plan an iteration. Commitment-driven iteration planning involves many of the same steps as velocity-driven iteration planning. However, rather than creating an iteration plan that uses the yesterday’s weather idea to determine how many story points or ideal days should be planned into the current iteration, the team is asked to add stories to the iteration one by one until they can commit to completing no more.

So what happens when a three point story is tasked out and comes to ten hours, and a five point story is tasked out and comes to nine? Often times the first inclination of the team is to inflate the three point story. Especially interesting is that almost no one suggests to shrink the estimate of the five point story. Again, we should expect that some three point stories will take the same amount of time to complete as some five point stories, but in the end this will even out.

Velocity is The Great Equalizer

Again from Mike Cohn’s Agile Estimating and Planning

What’s happened here is that velocity is the great equalizer. Because the estimate for each feature is made relative to the estimates for other features, it does not matter if our estimates are correct, a little incorrect, or a lot incorrect. What matters is that they are consistent. We cannot simply roll a die and assign that number as the estimate to a feature. However, as long as we are consistent with our estimates, measuring velocity over the first few iterations will allow us to hone in on a reliable schedule.

As the team complete more and more sprints, developers will come across three point stories that are a little larger than average and five point stories that are a little smaller than average. Between our bell curve distributions and velocity acting as the great equalizer, over time, the bumps in the estimations will smooth out and the desire to re-estimate stories will fade.

Agile Principles: Deliver Early and Often, but Always Deliver Value

The Agile Manifesto describes twelve principles of agile software. In a series of twelve blog posts, I will explore each principle.

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

This principle can be broken down into two separate thoughts. Continuously delivering early, and always delivering value.

Delivering Early and Often

Delivering early is more than just delivering something before the competition. Delivering early is more than just delivering before you would have had you not been being Agile™. Delivering early means specifically delivering less than you could have otherwise. Continuous delivery and iterative development are synonymous, it is not enough to just deliver early, you need to frequently do so.

Always Deliver Value

Delivering value is difficult. At a high level, it is difficult to know what is and is not valuable. Following the process and being disciplined can get you to a point where you are delivering early and often, but without a unified vision of what you are creating, it is very difficult to deliver real value.

Delivery early and often, but always deliver something of value.