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:
- The total capacity of the team in hours*
- The ability to estimate how many hours* a story will take to complete
- 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
- Add up the capacity of all team members to arrive at a total capacity
- Discuss each story as you would normally, defining done, exploring scenarios etc.
- Task out the story and add up the hours for each task
- The facilitator asks the team “Do you have enough capacity to commit to this story?”
- If the answer is “Yes” the team adds the story to their commitment
- If the answer is “No” the team moves on to another story, or breaks down the current story.
- 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?