Anti-Patterns: Sprint Planning - Part 3
Welcome to the third and last part of the Sprint Planning anti-patterns series. The first and second part of the series focused on the development team and product owner anti-patterns. In this part I will be focusing on the scrum team. Avoiding the following sprint planning anti-patterns will help, too.
Sprint Planning Anti-Patterns of the Scrum Team:
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 Scrum team regularly takes on way too many tasks and moves unfinished work simply 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 commitment 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 definition of ready is handled in a dogmatic way, 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 development team is not rejecting user stories that do not meet the definition of ready. This is the opposite side of being dogmatic about the application of DoR: not-ready user stories that will cause unnecessary disruptions during the Sprint are allowed into it. Laissez-faire does not help either.
The Sprint commitment 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 commitment. 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 commitment on behalf of the team. Whatever the reason is, the candidate should address the underlying issues.
The development team is not participating collectively in the Sprint planning. Instead, two team members, for example, the tech and UX leads, represent the team. As far as the idea of one or two ‘leading’ teammates in a Scrum team is concerned, there are none, see above. And unless you are using LeSS – no pun intended – where 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.
Thank you for reading.
