Scrum Sprint Planning Anti-Patterns (Hands-on Agile Webinar #5)

There is no shortage of Scrum anti-patterns, impeding your team’s ability to deliver value to your customers. This Hands-on Agile mini-series covers Scrum’s sprint planning ceremony.

The purpose of the sprint planning is to align the development team and the product owner. Both need to agree on the shippable product increment of the next sprint. The idea is that the development team’s forecast reflects the product owner’s sprint goal. Also, the team needs to come up with a plan on how to accomplish its commitment.

Easier said than done, it appears.

This Hands-on Agile webinar addresses 12 common sprint planning anti-patterns. Learn how to keep a simple scrum ceremony useful by avoiding typical mistakes, from pushy POs, toying with the definition of ready to obstructing the future flow by pushing utilization to 110%.

HOST: Stefan Wolpers

CONTENT:

(1) The first anti-pattern covers the lack of a sprint goal: The product owner cannot provide a sprint goal, or the chosen sprint goal is flawed.

(2) The second anti-pattern covers undiscussed spillovers: Unfinished user stories and other tasks from the last sprint spill over into the new sprint without any discussion. (There might be good reasons for that, for example, a task’s value has not changed. It should not be an automatism, though, remember the sunk cost fallacy.)

(3) The third anti-pattern covers the pushy PO: The product owner pushes the development team to take on more tasks than it could realistically handle. Probably, the product owner is referring to former team metrics such as velocity to support his or her desire.

(4) The fourth anti-pattern covers the introduction of a stage-gate like system by misusing the definition of ready: The definition of ready is handled dogmatically thus creating a stage-gate-like approval process.

(5) The fifth anti-pattern covers the imposed forecast of the scrum team: The sprint forecast is not a team-based decision. Or it is not free from outside influence.

(6) The sixth anti-pattern covers the case of overcommitment by the scrum team: The scrum team regularly takes on way too many tasks and moves unfinished work directly to the next sprint.

(7) The seventh anti-pattern covers variable sprint lengths: The scrum team has variable sprint cadences. For example, tasks are not sized to fit into the regular sprint length. Instead, the sprint length is adapted to the size of the tasks.

(8) The eighth anti-pattern covers the exclusion of some scrum team members from the sprint planning: The development team does not participate collectively in the sprint planning. Instead, two team members, for example, the tech and UX lead, represent the team.

(9) The ninth anti-pattern covers the failure of the development team to check its capacity in advance: The team members do not determine their availability at the beginning of the sprint planning. (Good luck with making a forecast in this situation.)

(10) The tenth anti-pattern covers missing slack time for the development team: The development team is not demanding 20% slack time from the product owner.

(11) The eleventh anti-pattern covers the misallocation of the development team’s resources: In addition to a lack of slack time, the development team is also not demanding adequate capacity to tackle technical debt and bugs during the sprint.

(12) The twelveth anti-pattern covers the sprint planning II: The development team is skipping the sprint planning II altogether.