For the last ten years, we have been helping teams in using the Scrum Framework effectively in their Daily work and delivering value every day. During that time, we learned one thing to be true: Scrum is easy to understand, but hard to master. As a consequence, many teams get caught up in Scrum misconceptions – partly also because of Scrum evolving.
Richard Forshaw, a Software Engineering Coach & Consultant, and I discussed some of the main misconceptions and how to solve them.
We came up with 4 main misconceptions:
- The Sprint Goal is a list of tasks
- Sprint Review is a Demo for the Product Owner
- The Daily Standup is for Reporting
- The Scrum Master is a Meeting Organiser
In the following article, we describe the first two. Head over to this article from Richard to find out more about the other two.
Scrum Misconception #1: The Sprint Goal is a list of tasks
As Agile Coaches, we often participate in Sprint Plannings with following patterns:
- The PO shows a list of items, they believe need to be developed in the upcoming sprint. The team discusses the individual items, often estimates them (which outcome has rarely an impact on the next steps).
- If it is a mature team, they might push back on 2-3 items, for being too big. But the PO begs or convinces the team long enough until the team agrees to commit to the Sprint Backlog provided by the PO.
- And before everyone leaves the room, one person (often, the Scrum Master) shouts: “Wait, we need a sprint goal”. And the team agrees to accomplish all items in the Sprint Backlog (duh).
While there are many issues in the example above (Ineffective estimations, PO pushing for certain output, commitment to Sprint Backlog, Planning as a handover from PO to team), the main problem is the understanding of a Sprint Goal.
What is a Sprint Goal?
To understand the Sprint, we look at the Scrum Guide: “The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives”.
“Accomplish all items in the Sprint Backlog” is a bad Sprint Goal. It is not a single objective for the sprint. And it also does not provide flexibility in terms of the exact work needed. Whenever we do creative or cognitive work, then any work progress provides feedback on what we can improve in the future. Scrum introduced the Sprint Goal, so we can allow flexibility in what and how we achieve user value. This means, even within the Sprint, we can change what to work on based on new information. Yes, that would make it necessary to change the Sprint Backlog. This is possible as long as it does not change the Sprint Goal. But if our Sprint Goal is about accomplishing the committed Sprint Backlog, this flexibility and reacting to daily new discoveries is impossible.
Sprint Goal describes the Why of a Sprint
With a Sprint Goal, we want to define, why it is valuable to enter into the Sprint. As most professional work is done towards a user or customer (external or internal), ideally Sprint Goals provide user value. Have in mind, that all work you do, provides at least indirect user value.
In many teams we have worked with, POs leave the definition of the Sprint Goal to the team. For them, it is important that the features of their roadmap are implemented. Therefore, they often accept bad Sprint Goals, such as “accomplish all items in the Sprint Backlog”.
Our suggestion is to make Sprint Goals strategic. Instead of painstakingly describing Roadmaps into different epics, features and stories with detailed acceptance criteria, we suggest creating a pool of Sprint Goals to start the conversation with your stakeholders as well as with the developers. A Sprint Goal can be an ideal interface between users/stakeholders and developers. It becomes then an easy exercise to tie the epic or feature ideas to the Sprint Goals.
How Sprint Goals helped top-performing teams
The best teams, we have worked with, always had the next three Sprint Goals available and transparent for both sides of the table. Obviously, these were moving targets and provided a rolling ideation and refinement process with enough flexibility to change, but still allowed some certainty over planning.
If there was any important feedback coming from the Sprint Review, the upcoming Sprint Goals still could change.
This, of course, changes the nature of a Sprint Planning. As described in the Scrum Guide, the developers commit to the Sprint Goal. To achieve this, the following approach to Sprint Planning could help:
- Coming from the roadmap, the PO suggests the sprint goal for the upcoming sprint alongside the Product Backlog Items, they believe will help to achieve this.
- Team and PO discuss and clarify (and estimate for alignment and slicing decision purposes) story by story, until the team says that it is enough for the sprint.
- Finally, the team confirms that the items chosen will contribute to achieve the Sprint Goal. Or they suggest an updated one. In the end, the Scrum Team commits to achieve the Sprint Goal.
So, Sprint Goals should be strategic, provide user value and should provide flexibility. The Sprint Goal creation should be a collaborative task between the PO and the developers, and the developers should commit to it (it may be sometimes better, if the PO commits to it as well, so Sprint Goals cannot change easily).
Scrum Misconception #2 Sprint Review is a Demo for the Product Owner
Many Scrum Teams believe the purpose of the sprint review is to demonstrate the work outputs to the Product Owner. This results in reviews becoming team-internal demos in which the Product Owner signs off on individual tickets. Sometimes, they may agree with a feature, but before a release, they want to change the color of a button.
However, when real user feedback starts coming in the next sprint, it can reveal that the developers need top improve some of the already released features. This affects the team’s focus on the new Sprint Goal.
If we are looking at the Scrum guide, it says that the Sprint Review is “to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.”
In our example above, the audience of the Sprint Review are not the Stakeholders, but the Product Owner. What many teams forget: While the Product Owner is the voice of the Stakeholder, they are not exactly them. If a team needs to constantly improve already released features, it may be a symptom, that developers do not build a product for the users, but for the Product Owner.
Product Owner is not the recipient, but an active part of the Review
To make a Sprint Review more effective, we suggest that the Product Owner spends as much time with the developers within the Sprint as they do with the Stakeholders. Through that, misunderstandings, lacking design decisions or quick bug fixes can be verified immediately. The team stays in synch with the Product Owner daily, which may shorten the feedback cycle from 1-2 weeks to just under a day.
This additionally creates transparency over the progress towards the Sprint Goal. And it prevents that in Sprint Reviews the discussions are about the color of a button but focuses on the product as a whole by inspecting the delivered increment.
If the developers are more in synch with the PO during the sprint, the Sprint Review can focus on the achievement of the Sprint Goal. This invites Stakeholders to provide feedback and suggest adaptations immediately. The progress towards the product goal is visible for the Scrum team as well as the Stakeholders.
Example Agenda for a Sprint Review
The best reviews are hosted and led through by the Product Owner and may have the following agenda:
- Product Owner (PO) presents the Sprint Goal.
- PO gives an overview of the features/stories, which were covered to achieve the Sprint Goal.
- Developers quickly demo the increment of those features (not in video, but by using the features) with a quick feedback round from the stakeholders. They might ask to dig deeper into specific parts of the increment to provide more detailed feedback.
Based on that, the PO discusses, why the stakeholder’s inputs can or cannot be considered, and adds it to the Product Backlog if needed.
While this part is technically the demo, the participants should allow for an open discussion here. The Scrum Master facilitates to ensure it stays within the timebox. - If still have time, Product Owner and developers can present delivered work, which was not part of the Sprint Goal (additional features, bug-fixes, refactoring work, security updates, etc.).
- Stakeholders share any information about any feature requests, which the PO can take on for further analysis or quick discussion.
- Product Owner summarizes the Sprint Review and gives the forecast of the potential Sprint Goal for the next sprint (and if it may be affected by any of the prior discussions).
As you can see, the demo is only a part of the Sprint Review and is not its goal. The Product Owner is an active part of the review process, but feedback comes from the stakeholders.
Conclusion
From analysing these two Scrum misconceptions alongside the two from Richard, we can see that Scrum is one big jigsaw: if you do not set the right Sprint goals, then you will be setting your team up for potential failure because they will not have the ability to optimally self-organise to achieve the goal. If the Daily Scrum is about reporting task completion, then the team will be limited to simply re-shuffling the tasks they are given, not empowered to regularly decide how to best achieve the goal. If the Sprint Review is only a demo to the Product Owner, then the team misses out on valuable feedback to see if the goal has actually been delivered, and also influences the next goal. The Scrum Master is there to help the team in understanding this and ensuring it does not happen.
About the collaborator
Richard has been in Software Development and Delivery for over 20 years. He is passionate about using teams and technology effectively, from small teams and new products to large and mature systems, from development techniques to architecture and DevOps. Richard recently lived in Malaysia and now he is in Vietnam. He is excited to bring his experience to software companies in Vietnam, to help them improve their teams, techniques and technology to give better outcomes.
