Hands-on Agile Webinar #5: Sprint Planning Anti-Patterns

TL;DR: Webinar Sprint Planning Anti-Patterns

Webinar Sprint Planning: The purpose of Scrum’s 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 forecast.

Easier said than done, it appears. Therefore, the fifth Hands-on Agile webinar addresses 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%.

The videos of the webinar are available now:

Note: If the browser will not play the playlist automatically, click here to watch the Webinar Sprint Planning Anti-Patterns playlist directly on Youtube.

Webinar Sprint Planning Anti-Patterns: The Episodes

• The first episode covers the lack of a sprint goal: The product owner cannot provide a sprint goal, or the chosen sprint goal is flawed. (An original sprint goal answers the “What are we fighting for?” question. It is a negotiation between the product owner and the development team. It is focused and measurable, as sprint goal and team forecast go hand in hand. Lastly, the sprint goal is a useful calibration for the upcoming sprint.)
• The second episode 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.)
• The Third episode 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.
• The fourth episode 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. (That is an interesting topic for a discussion among the team members. For example, should a valuable user story be postponed to another sprint just because the front end designs will not be available for another two working days? My suggestion: take it to the team. If they agree with the circumstances and accept the user story into the sprint — that is fine.
• The fifth episode 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. (There are several anti-patterns here. For example, an assertive product owner dominates the development team by defining its scope of the forecast. Or a stakeholder points at the team’s previous velocity demanding to take on more user stories. (“We need to fill our free capacity.”) Or the ‘tech lead’ of the development team is making a forecast on behalf of the team.)
• The sixth episode 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. (If two or three items spill over to the next sprint, so be it. If regularly 30-40 percent of the original forecast is not delivered during the sprint the scrum team may have created a kind of ‘time-boxed Kanban.' Maybe, this is the right moment to ask the scrum team whether moving to Kanban might be an alternative.)
• The seventh episode 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. (It is quite common to extend the sprint length at the end of the year when most of the team members are on holiday. However, there is no reason to deviate from the regular cadence during the rest of the year. Instead of changing the sprint length, the scrum team should invest more effort into sizing epics and user stories in the right way.)
• The eighth episode 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. (Regarding the idea of one or two ‘leading’ teammates in a scrum team, there are none. And unless you are using LeSS – no pun intended – where the scrum teams are represented in the overall sprint planning, the whole scrum team needs to participate. It is a team effort, and everyone’s voice hence needs to be heard.)
• The ninth episode 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.)
• The tenth episode covers missing slack time for the development team: The development team is not demanding 20% slack time from the product owner. (If a team’s capacity is always over-utilized, its performance will decrease over time. This will mainly happen in an organization with volatile daily business. As a consequence, everyone will focus on getting his or her tasks done. There will be less time to support teammates or to pair. The team will no longer address smaller or urgent issues promptly. Individual team members will become bottlenecks, which might seriously impede the flow within the team. Lastly, the ‘I am busy’ attitude will reduce the generation of a shared understanding among all team members. Overutilization will always push the individual team member to focus on his or her output. On the other side, slack time will allow the scrum team to act collaboratively and focus on the outcome.)
• The eleventh episode 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. (The rule of thumb is that 20 to 25 % of resources are allocated every sprint to fix bugs and refactor the code base. If the product owner ignores this practice, and the development team accepts this violation the scrum team will find itself in a downward spiral. Its future product delivery capability will decrease.)
• The twelveth episode covers the sprint planning II: The development team is skipping the sprint planning II altogether. (Skipping the sprint planning II is unfortunate, as it is also an excellent situation to talk about how to spread knowledge within the development team. For example, the team should think about who will be pairing with whom on what task. The sprint planning II is also a well-suited to consider how to reduce technical debt. Alternatively, during sprint planning II, the development team plans every single subtask of the upcoming sprint. (Don’t become too granular. Two-thirds of the sub-tasks are more than sufficient, the rest will follow naturally during the sprint. Doing too much planning upfront might result in waste.)
• The last episode summarizes the dirty dozen of sprint planning anti-patterns: They start with the lack of a sprint goal and do not end with a neglected or overly accurate sprint planning II. Don’t miss the next Hands-on Agile mini-series on Scrum anti-patterns and subscribe to this Youtube channel.)

Download the ’Scrum Anti-Patterns Guide’ for Free

The ’Scrum Anti-Patterns Guide’ is another free ebook from the Hands-On Agile series of practical guides from the trenches. It covers more than 160 scrum anti-patterns that hold your scrum team back.

By filling out following form, you explicitly consent to three things:

1. Receiving a download link to this PDF by email.
2. Subscribing to the ’Food for Agile Thought’ newsletter with 17,000-plus subscribers.
3. Authorizing our newsletter service provider ConvertKit to process your data to deliver newsletters.

European subscribers can define — or skip — marketing permissions in the following step.

?? Subscribe to Age of Product’s Brand-New Youtube Channel

Now available on the Age of Product Youtube channel:

• ?? Hands-on Agile Webinar #5 on sprint planning anti-patterns.
• Hands-on Agile Webinar #3 on agile failure patterns.
• Hands-on Agile Webinar #1 on product discovery anti-patterns.

? Do Not Miss Out: Join the 3,450-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

?? Do you want to read more like this?

Well, then:

• ?? Join 17,791 peers and sign-up for my weekly newsletter
• ?? Follow me on Twitter and subscribe to my blog Age of Product
• ?? Alternatively, join 3,450-plus peers of the Slack team “Hands-on Agile” for free.

Hands-on Agile Webinar #5: Sprint Planning Anti-Patterns was first published on Age-of-Product.com.