After a few months of downtime and a lost backup, I’m slowly resurrecting my blog from old backups and markdown files. In the mean time, feel free to browse on The Way Back Machine archive of claytonlz.com.
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:
- 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.
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?
Use this retrospective exercise when you want to help a team set expectations, practice empathy and generate working agreements that move the team forward.
For this retrospective you’ll need sharpies, post-it notes and a wall, window or whiteboard on which they can be stuck.
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
- 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.
- 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)
- 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
Now that some ideas have been generated, move the participants towards gaining insight by grouping them in like categories.
- Using Mute Mapping, have the participants group the stickies, while keeping them in their Scrum Master, Product Owner and Development Team boxes.
- 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
Recently, on twitter, Tobias Mayer asked if anyone was still using burndown charts as described in the original scrum literature:
I personally enjoy using burndown charts and like exploring the different stories they can tell given the multitude of ways you can design them. I am currently working with a team that is using a commitment driven approach to planning who also uses a burndown chart of remaining task hours. I replied to Tobias with:
This seemed to spark a big discussion with a lot of people chiming in with their opinions and experiences. The discussion followed the usual Agile Twitter Debate Formula™ involving charges of not being agile, assuming mutual exclusivity with other practices, general misinterpretations of various points concluding with the usual series of just-do-what-you-want-and-lets-stop-arguing-about-this tweets.
Since twitter proves time and again to be a terrible place to expand on things, I figured it was worth explaining my original tweet in a little more detail here.
Value vs. Work
One of the first issues that came up in this discussion was that the sum of tasks for a particular user story don’t necessarily add up to any real meaningful value, so since tasks themselves don’t represent value, we shouldn’t be tracking them.
So, fair enough, tasks don’t represent value so let’s track story points instead. While I think that a burndown chart of story points can tell a story, I like to tell lots of stories so I usually use this in conjunction with other artifacts. I’ve also seen plenty of teams who have a burndown chart of story points that goes sideways for three days and then everyone realizes that they’re not going to get everything done by the end of the sprint. Whoops!
Do we have enough gas to get there?
Imagine that you and some friends are planning a road trip to an outdoor music festival. You all hop in the car and get going. Being a beautiful day, you suggest taking the scenic route and stopping on the way to take a group photo. As you’re driving, the GPS on your dashboard is squawking commands and you’re fairly confident that you’re heading in the right direction. After a few hours someone in the backseat asks “Hey, do we need to stop and get gas?”
At that moment you look down and realize that you’ve got a quarter tank left, with some quick math and a glance at the GPS you determine that you do not have quite enough gas to make it to the music festival and having passed the last gas station before your destination you can’t stop and get more. Your only choice is to break the bad news to your friends and negotiate taking the group photo on the way back from the music festival.
Are We on Track?
I view a burndown chart of hours remaining as a gas gauge. It doesn’t tell us anything about if we’re going in the right direction or if we’ll ultimately get to our destination, but it can be a useful way of making sure that you’ve got what it takes to make it there.
Most importantly, tracking hours remaining isn’t about tracking hours, or management making sure people are busy or any of the other treacherous things suggested during this twitter discussion. For me, tracking hours remaining is about all of the questions and things you uncover as a result of asking “Are we on track?” and the answer that follows.
I was recently fortunate enough to attend the Culture Conference in both Philadelphia and Boston. Even more so, I was able to enjoy the company, conversation and new relationships as a member of the party bus that traveled between the two conferences.
As we drove over the George Washington Bridge, I was having a conversation with Dan Mezick about the role of Agile Coaching in ethical billing and creating learning organizations. I’m a firm believer in the idea that as Agile Coaches, we should strive to foster an environment of organic learning and prescribe specific solutions only when absolutely necessary.
As Dan and I were talking, it occurred to me that an Agile Coach has a similar role to a planted aquarium hobbyist. One can think of a typical organization as a poorly maintained aquarium. There are frequent algae blooms, some of the fish have died, and the plants have discolored leaves and weak roots.
If handed over to an accomplished aquarium hobbyist, they would start by measuring chemical levels in the water to asses the environment. With continuous checking, day by day and week by week, our hobbyist would slowly adjust and improve the balance in the tank. They might add or remove certain plants, invertebrates or fish. Over time, as a result of their actions, the aquarium would achieve a state of balance and the inhabitants would enjoy a harmonious co-existence.
Similarly, an Agile Coach might enter a dysfunctional organization and begin measuring and improving the organizational environment. Again, like the hobbyist, they would help the organization adjust its culture such that it too could become a thriving, self-sustaining ecosystem where the inhabitants live in balance and harmony.
This isn’t to say that once this state is achieved, the coaches work is finished. Just as the hobbyist needs to maintain the aquarium by adding and removing plants or fish, an organization committed to continuous improvement needs the help of the coach to keep learning and improving.
As Agile Coaches, I hope that we strive to build self-sustaining learning organizations rather than insert ourselves as linchpins in the ecosystem. I strive for the self-awareness to ask of myself “Am I just adding chemicals or am I helping the roots grow deeper and fish prosper?”
Working software is the primary measure of progress.
– Principles behind the Agile Manifesto
Pixel perfect design mockups, UML diagrams, detailed user stories, automated tests, thousands of lines of code and hours of discussions. These are just a few examples of the endless amount of stuff we can spend time creating, tweaking, editing, testing and reviewing. However, nothing shows progress quite like working software.
So what is working software? That’s going to be different for every team, but a good starting point might be “software that is deployed to and delivers value to the customer”. This means it might be ugly, imperfect, not-absolutely-intuitive and likely somewhat incorrect and that’s okay; you’re one step closer to making it meaningfully better.
This post is part of my series on the principles behind the agile manifesto. You can find the others here:
- Agile Principles: Tear Down These Cubes
- Agile Principles: Self-Organizing Teams are Motivated Teams
- Agile Principles: Collaborate Everyday
- Agile Principles: Frequently Deliver Working Software
- Agile Principles: Iterate. Evaluate. Repeat.
- Agile Principles: Deliver Early and Often, but Always Deliver Value