Generally, this word can be used for any Agile Practice but, we will focus on the word by using the Scrum Framework for context. From a Scrum point of view we can understand commitment based planning as something that takes place between sprints.

Planning, for an agile team, is actually a commitment that the Team makes. In Scrum, this commitment is based on a negotiation between the Productcommitment planningOwner and the rest of the Team, where the Product Owner is speaking for all the Stakeholders that are outside the Team.

For more read  commitment-Based planning, and the major issues that arise when doing it.

Commitment-Based planning begins with the Product Owner having a collection of Stories sufficient to fill the Sprint. Typically, you would expect up to two or three Sprint’s worth of stories to be available, with a minimum of 1¼ sprint’s worth. See the chapter on Backlog Grooming (xx) for discussion of getting stories ready for planning.

  1. At the beginning of planning, the Team discusses the overall goals and priorities, and the PO selects a single story to consider (the highest priority).  The Team (including the Product Owner) negotiates the “doneness” Agreement for this single story, and the Team (without undue influence from the Product Owner, or consideration of the Story’s size in SPs) commits to this single story. What they are actually committing to is the “doneness” Agreement, which we typically simply refer to as the story’s Agreement.
  2. The Team may not be able to commit to a story, or might not even be able to agree on “done.” This makes the story in question an epic, by definition, and the Team must decide what to do. Typical choices include committing to an Analysis Story to figure out what to do about the epic, or extracting a smaller story from the epic to do instead (putting the remainder back on the backlog), or skipping the story altogether and moving to the next one.
  3. After a Story is committed to, the Team (with the PO in the lead) has the option to reprioritize the Story list, and the Team takes the next one to consider. Once again, the Team comes to the “doneness” Agreement and commits to adding the Story to the list of already-committed-to Stories. This process is repeated until the Sprint is “full” and the Sprint Plan is complete.

Summary:

This process is quite simple, but leads to a number of issues that are tightly intertwined.

A useful contrast is Velocity-Based Planning vs. Commitment-Based planning. Generally,  Commitment-Based planning is better than Velocity-Based planning for most agile teams.

0 comments