Do you plan for success when conducting sprint planning? In a misunderstood urge of striving for success many teams over commit when planning sprints. This can often be witnessed at sprint demos where many of the user stories planned for implementation are either not fully done or not even started.

This is a rookie mistake.

When doing sprint planning it’s very important to have the full overview of the team’s capacity at hand. This means that all team members report their planned availability and sum it in a capacity plan.

This capacity should be divided into two major categories:

• Planable capacity: The effective capacity of the team for implementing user stories in the sprint.
• Unplanned capacity: The remainder of the team capacity which is not planned.

The reason for having unplanned capacity is that the capacity plan holds the sum of hours that the team member is using in the office. However, this number does not account for unplanable events such as getting coffee, celebrating anniversaries, helping other team members, etc.

To accommodate the nature of unplanable work in a sprint, a load factor is introduced. This load factor indicates the estimated work load that the team is effectively able to produce.

When starting a sprint the load factor is typically very low (<50 %) due to uncertainty of project scope etc. Over the project period this number should be increased as the team gets more and more specific on the scope and goals of the project scope.

Caveat: Having a very high load factor when adopting agile methods leads to frustration within the team. Why they are not able to deliver what has been promised? Is the agile methodologies not fast enough? Set the initial bar low and aim for successes instead of failures. During the sprint, the team is allowed to take in new tasks from the top of the product backlog – which will prevent the team from loosing cadence. Presenting more completed user stories at the sprint demo meeting is better than showing fewer than planned!