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:
In the following article, we describe the first two. Head over to this article from Richard to find out more about the other two.
As Agile Coaches, we often participate in Sprint Plannings with following patterns:
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.
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.
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.
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:
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).
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.
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.
The best reviews are hosted and led through by the Product Owner and may have the following agenda:
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.
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.
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.
|_GRECAPTCHA||5 months 27 days||This cookie is set by the Google recaptcha service to identify bots to protect the website against malicious spam attacks.|
|cookielawinfo-checkbox-advertisement||1 year||Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .|
|cookielawinfo-checkbox-analytics||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".|
|cookielawinfo-checkbox-functional||11 months||The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".|
|cookielawinfo-checkbox-necessary||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".|
|cookielawinfo-checkbox-others||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.|
|cookielawinfo-checkbox-performance||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".|
|ppwp_wp_session||30 minutes||No description|
|_ga||2 years||The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.|
|_ga_8T1CV8HV5N||2 years||This cookie is installed by Google Analytics.|
|_gat_gtag_UA_28003764_1||1 minute||Set by Google to distinguish users.|
|_gcl_au||3 months||Provided by Google Tag Manager to experiment advertisement efficiency of websites using their services.|
|_gid||1 day||Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.|
|test_cookie||15 minutes||The test_cookie is set by doubleclick.net and is used to determine if the user's browser supports cookies.|