Hands-on Agile: Sprint Planning Anti-Patterns [Webinar]
Hands-on Agile: Sprint Planning Anti-Patterns [Webinar]
Sprint planning is the first and one of the most essential steps to a successful project. Take a look at this webinar series about what you shouldn't do.
Join the DZone community and get the full member experience.Join For Free
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.)
Agile Transition – A Hands-on Guide from the Trenches
The Agile Transition – A Hands-on Guide from the Trenches e-book is a 212-page collection of articles I have been writing since October 2015. They detail the necessary steps to transition an existing product delivery organization of over 40 people strong to Agile practices.
Published at DZone with permission of Stefan Wolpers , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.