Recognizing a Disastrous Scrum Sprint Before It Starts
The best way to recognize a disastrous sprint before it starts is by looking at the sprint goals. A successful sprint depends on many factors, but there are telltale signs that a sprint has a high risk of failure. Let’s start with an example of a problematic set of sprint goals and dissect why they increase the chance of not completing the sprint goals.
Sprint 1
Length 4 weeks
Sprint Goals:
* Create the product view [Sal]
* Create the shopping cart [Jill]
* Create the checkout [Jack, Bob]
* Create seller product management view [Mina, Alice]
* Create the user accounts [Alice]
* Fix bugs for release [Bob, Jack, Jill, Sal]
* Setup database [Daniel, Jill]
The first problem is the number of sprint goals is equal to the number of members on the team. If the team has seven members and there are seven sprint goals, it’s more complex to keep track of all the progress toward the goals and has a higher chance of falling into a scrum antipattern. The worst-case scenario is all seven sprint goals are worked on in parallel and each team member is working individually on their own piece. Alice doesn’t talk to Sal because their goals don’t relate and Bob is siloed as he is only fixing bugs. Another problem is there may be complex dependencies between goals. The checkout has dependencies on the shopping cart and user account. Shopping cart…
