Making the most of Scrum: Avoid these MisconceptionsMaking the most of Scrum: Avoid these MisconceptionsMaking the most of Scrum: Avoid these MisconceptionsMaking the most of Scrum: Avoid these Misconceptions
    • Our Expertise
      • Increase Effectiveness
      • Align & Focus
      • Agile Leaders
      • Autonomous Teams
    • Our Insights
    • Our Offer
    • Our Agile Trainings
    • About Us
      • Our Achievements
      • Contact Us
      • Sign up to our newsletter
    • 4 Pillars
    • Academy for Agile Coaches
    0

    0 ₫

    • Academy Login

    Making the most of Scrum: Avoid these Misconceptions

    • Home
    • Insights
    • Agile Team Enablement Agile Delivery
    • Making the most of Scrum: Avoid these Misconceptions
    Published by Chris Kruppa on December 13, 2022
    Portrait Photo of Woman in Red Top Wearing Black Framed Eyeglasses Standing In Front of White Background Thinking

    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:

    1. The Sprint Goal is a list of tasks
    2. Sprint Review is a Demo for the Product Owner
    3. The Daily Standup is for Reporting
    4. 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:

    1. Product Owner (PO) presents the Sprint Goal.
    2. PO gives an overview of the features/stories, which were covered to achieve the Sprint Goal.
    3. 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.
    4. 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.).
    5. Stakeholders share any information about any feature requests, which the PO can take on for further analysis or quick discussion.
    6. 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.

    Share
    Chris Kruppa
    Chris Kruppa
    Chris is a German working in Vietnam since 2008. He became passionate on Agile, when he started to implement Agile into his Marketing team about 2010. He immediately saw the impact of cross-functional and transparent teams and became a CSM in 2011. He founded semdi solutions in 2012 with the goal to coach teams on how to be more adaptive and ready for the 21st century. Since then, he has worked with nearly 20 organizations in Southeast Asia and supported them in increasingly becoming more Agile.

    Related posts

    What is Agile? True Agile is rarely visible in it's process
    January 5, 2023

    Agile: More than Just a Framework


    Read more
    The Future of Agile is depending on how we handle change.
    November 29, 2022

    The Future of Agile


    Read more
    10 Agile Misconceptions
    November 22, 2022

    10 Agile Misconceptions


    Read more

    Leave a Reply Cancel reply

    Your email address will not be published. Required fields are marked *

    Logo semdi solutions

    semdi solutions Co. Ltd.

    Level 14, Saigon Center 1
    65 Le Loi
    Ward Bến Nghé, District 1
    Hồ Chí Minh City

     
    • Contact
    • Imprint
    • Privacy Policy
    semdi solutions, © 2022
      0

      0 ₫

      • Academy Login
      ✕

      Login

      Lost your password?

      We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.
      Read More about our privacy policy
      Cookie SettingsAccept All
      Manage consent

      Privacy Overview

      This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
      Necessary
      Always Enabled
      Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
      CookieDurationDescription
      _GRECAPTCHA5 months 27 daysThis cookie is set by the Google recaptcha service to identify bots to protect the website against malicious spam attacks.
      cookielawinfo-checkbox-advertisement1 yearSet by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .
      cookielawinfo-checkbox-analytics11 monthsThis 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-functional11 monthsThe cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
      cookielawinfo-checkbox-necessary11 monthsThis 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-others11 monthsThis 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-performance11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
      viewed_cookie_policy11 monthsThe cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
      Functional
      Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
      CookieDurationDescription
      ppwp_wp_session30 minutesNo description
      Performance
      Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
      Analytics
      Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
      CookieDurationDescription
      _ga2 yearsThe _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_8T1CV8HV5N2 yearsThis cookie is installed by Google Analytics.
      _gat_gtag_UA_28003764_11 minuteSet by Google to distinguish users.
      _gcl_au3 monthsProvided by Google Tag Manager to experiment advertisement efficiency of websites using their services.
      _gid1 dayInstalled 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.
      Advertisement
      Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
      CookieDurationDescription
      test_cookie15 minutesThe test_cookie is set by doubleclick.net and is used to determine if the user's browser supports cookies.
      Others
      Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.
      SAVE & ACCEPT
      Powered by CookieYes Logo
      Pre-register for our 4 Pillars Guide

      "*" indicates required fields