Anti-Patterns: Sprint Planning - Part 2
Welcome to the second part of the Sprint Planning anti-patterns series. The first part of the series focused on the development team anti-pattern. In this part I will be focusing on the Product Owner. Avoiding the following sprint planning anti-patterns will help, too.
Sprint Planning Anti-Patterns of the Product Owner:
The product owner cannot provide a Sprint goal, or the chosen Sprint goal is flawed. An original sprint goal answers the “What are we focusing on?” question. It is a negotiation between the product owner and the development team. It is focused and measurable, as Sprint goal and team commitment go hand in hand. Lastly, the Sprint goal is a useful calibration for the upcoming Sprint.
The Sprint backlog resembles a random assortment of stories, and no Sprint goal is defined. If this is the normal way of finishing your Sprint planning 1, then probably the Scrum is not the right framework to use. Depending on the maturity of your product, Kanban may prove to be a better framework. Otherwise, the randomness may signal a weak product owner who listens too much to stakeholders instead of prioritising the product backlog appropriately.
Unfinished user stories and other work 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.
The product owner tries to squeeze in some last-minute user stories that do not meet the definition of ready. Principally, it is the prerogative of the product owner to make these kinds of changes to ensure that the development team is working only on the most valuable user stories at any given time. However, if the Scrum team is otherwise practicing product backlog refinement sessions regularly, these occurrences should be a rare exception. If those happen frequently, it indicates that the product owner needs help with prioritisation and team communication. Or the product owner needs support to say ‘no’ to stakeholders. Or coach the stakeholders with the assistance of the scrum master.
The product owner pushes the development team to take on more work than it could realistically handle. Probably, the product owner is referring to former team metrics such as velocity to support his or her desire (this would be an opportunity for the candidate to step in and address the issue).
Thank you for reading, the next article will be on Scrum Team Sprint Planning anti-patterns.
