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.

WARNINGThe 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?

 

 

The 7 Bullshit Agile Estimation Problems

Estimating stories for an upcoming project is one of the more difficult tasks that agile teams have to perform. It’s never easy to determine how difficult it will be to implement a particular feature, especially when you’ve got different personalities, goals, and levels or experience in the same room. Unfortunately this all leads to people coming up with excuses and roadblocks which lead to inaccurate estimates.

I’ve identified seven problems pitfalls of the agile estimation process that I’m sure many other teams have experienced:

1) Estimating Time Rather Than Complexity

The point of estimating stories with planning poker cards is that you estimate based on the story’s complexity, not on how long it will take you to complete the actual feature. A story that’s an 8 is more complex than one that’s a 5, but it doesn’t meant that the 8 will take two days. It could take an hour or a week, it’s all relative.

Why it’s Bullshit
Estimates based on time make planning commitments difficult and velocities unreliable.

2) Not Estimating For “Simplest Possible Solution”

The “Simplest Possible Solution” is just that, what’s the simplest way that the feature described in the story can be implemented. When you get away from this you start going down all sorts of “what if” roads that always end up bumping up your estimate.

Why it’s Bullshit
Trying to guess what the product owner will want or what the completed feature entails is a waste of time.

3) I’ve Never Done That Before

There aren’t many software problems that haven’t been solved. Most of them are things that have been solved a thousand times in a hundred different ways. Adding complexity to a story because you’ve personally never solved that problem is shortsighted.

Why it’s Bullshit
Just because you’ve never done something doesn’t mean it’s complex. Lean on your team or network of developer peers to help solve these problems.

4) Estimating Stories In Excessive or No Isolation

Stories should be estimated in isolation, just as they should be written so as not to depend heavily on one another. However, developers will often try to assign too much complexity to a story because of assumed tasks or features that they think would accompany the story in a completed state. For example:

As a user I should be able to login
As a user I should be able to upload a profile photo
As a user I should be able to change my address

Some developers will see the first story and immediately think of the complexity of creating a user model, the controllers and views that go along with the entire registration process.

Alternatively some developers will see the last story and think “Oh I just need a form field for the e-mail address when the user is editing their profile.”

Why it’s Bullshit
The first extreme gives you chunks of related stories with too much padding that are never as complex individually as they are as a whole. The latter only (sometimes) works when the actual stories are extracted out into a bunch of very small stories, which has its own set of problems.

5) Gaming Velocities

If you’re looking to “guesstimate” how long a project will take to complete, you could grab some story cards and pick out what you think might be a week of work. If you add up the points assigned to those stories you’d have an estimated velocity. However, if you’ve padded your stories, or purposefully pick out a small number of stories, your project is going to appear much lengthier than it really is.

Why it’s Bullshit
You don’t look any better completing 50 points per iteration when you padded the hell out of your estimates than you do when you do 20 points per iteration with accurate estimates.

6) Always Assume The Worst!

There seems to be this mantra with some developers, “Always assume the worst!” When you come across a slightly vague story, let your imagination run wild and assume that the product owner is going to want the most complex solution possible.

Why it’s Bullshit
Remember, every story is a negotiation. You’re not going to know the exact details of the story until you have your planning meeting with the product owner. Often times the product owner would never have been able to dream up the solution on which you based your estimate.

7) Padding Padding Padding

Padding is all Bullshit
The problem of padding estimates creeps into nearly all of the above six issues. It introduces bad data early in the life of the project and makes every other step of the process unreliable. It’s almost always in an effort to cover one’s ass but it’s painfully transparent and reeks of amateurism.

Don’t pad your estimates.