The scrum process involves many type of events. There is the sprint planning, the daily stand up, sprint review, and sprint retrospective. When the steps of the scrum process are follow through correctly, the rest of the sprint will flow more smoothly. However, there are many pitfalls in each of the scrum events that can derail the whole scrum process. In the article, The 5 Most Common Pitfalls of the Scrum Events by Barry Overeem, the author points out some of the most common pitfalls of the scrum events.
One of the most important event in the scrum process is the sprint planning. The author of this article points out these 5 pitfalls for sprint planning.
- Having a Product Owner who doesn’t have a Sprint Goal in mind.
- Using a Product Backlog that isn’t refined enough.
- Not knowing the velocity and upcoming capacity of the Development Team.
- Not taking the Definition of Done into account when crafting the Sprint plan.
- Ending the Sprint Planning without a shared commitment on the Sprint plan and its goals.
Similar to project planning, sprint planning involves having a clearly defined scope and goal for the sprint. During sprint planning, the role of the product owner is to set the goal of the sprint. The product owner is the one that should be setting the priority of what product backlogs need to be done and when they need to be done by. The product owner should also know the relative effort it will take to get each of the product backlogs done so that they can come up with a schedule for the scrum team for the sprint. It is also the responsibility of the product owner to make sure each of the product backlog has a completed story and a clear condition of satisfaction in order to define what done is. The scrum team will then have a better understanding of each of the backlog selected and be able to concentrate on how to complete each of the backlog.
Another important event of scrum is the daily stand up. The author of the article has these 5 pitfalls for this event.
- Not doing the “Daily” Scrum every day
- Considering the Daily Scrum as a status-update towards the Scrum Master
- Not having a shared and clear Sprint Goal as the main indicator
- Focus on detailed activities instead on the actual results the team has achieved
- Not updating the Sprint Backlog during the Daily Scrum
The daily stand up should be held daily as the name implies. It should be short and to the point. The purposed of the daily stand up is to give not only the scrum master but also the team on what has been completed and reveal any road blocks that prevent the team from reaching the sprint goal. If there are any issues, it should be raised so that the team as a whole can help resolve the issue. The daily stand up should be more than just status reports and what activities has been done. Rather, it should be about the team and all members working as a team to accomplish the sprint goal.
Another important event of scrum is the sprint review. The author of this article has these 5 pitfalls for this event.
- Considering the Sprint Review only as a demo.
- Demonstrating the results to the Product Owner, instead to the stakeholders
- Not inviting any stakeholders and hereby neglecting gathering feedbacks on the increment, Sprint and Product Backlog
- Cancelling the Sprint Review because “there’s is nothing to demonstrate”
- Don’t letting the Development Team attent the Sprint Review because they’ve got more important stuff to do.
Sprint Review should be more than just a demo to the product owner. It should involve stakeholders and developers. Developers should use this opportunity to show everyone what they have accomplished in the sprint and collect additional feedback and requirements for future sprints. The demo should be used as a tool to open up new ideas, questions, issues, and discussions. The sprint review increases accountability for the team and ensures everyone is on the same page. It reduces testing down the road and make sure there are no surprises at the end.
Finally, another important event of scrum is the sprint retrospective. Here the author of the article gives these 5 pitfalls.
- Cancelling the Sprint Retrospective because “there’s nothing to improve”
- Cancelling the Sprint Retrospective because “we don’t have enough time to improve”
- Using the same format over and over again
- Having far too much ambiguously defined improvements as a result
- Not having any committed improvements with a clear plan of approach for the upcoming Sprint.
Agile is all about continuous learning and improvement. The sprint retrospective plays a big part in this principle. During the retrospective, the team shares what worked and what didn’t work. The team should continue to do the things that worked for them and find ways to improve on things that didn’t work. For the things that didn’t work, the team should come up with specific actionable tasks and follow through on them. There is always room for improvements and time spent in the retrospective will reduce the time spent in future sprints on repeated mistakes.