General

I suggest you ...

You've used all your votes and won't be able to post a new idea, but you can still search and comment on existing ideas.

There are two ways to get more votes:

  • When an admin closes an idea you've voted on, you'll get your votes back from that idea.
  • You can remove your votes from an open idea you support.
  • To see ideas you have already voted on, select the "My feedback" filter and select "My open ideas".
(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

  1. Scrum Master should promote and support Scrum, not enforce and police it.

    In "The Scrum Master" chapter it says:

    "The Scrum Master is responsible for ensuring Scrum is understood and enacted".
    Change to: "The Scrum Master is responsible for promoting and supporting the Scrum implementation"

    Then it says "Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules."
    Change to: "Scrum Masters do this by helping everyone understand Scrum theory, practices, and rules."

    Rationale for change: this whole paragraph makes the SM a process enforcer rather than a servant leader. Suggesting a better way of phrasing it.

    189 votes
    Vote
    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      You have left! (?) (thinking…)
    • Don't prescribe exactly the exact length of sprint review & retro

      In the "Sprint Review" section it says: "This is a four-hour time-boxed meeting for one-month Sprints."
      Change to "This is at *at most* a four-hour time boxed meeting for one-month Sprints".

      Same with Sprint Retrospective. Change to "at most a three-hour time-boxed meeting".

      Rationale: No need to prescribe an exact length. A max length makes more sense. Shorter is often better. Plus, this is consistent with how sprint planning meeting is described ("time-boxed to a maximum of eight hours for a one-month Sprint").

      145 votes
      Vote
      Sign in
      Check!
      (thinking…)
      Reset
      or sign in with
      • facebook
      • google
        Password icon
        I agree to the terms of service
        Signed in as (Sign out)
        You have left! (?) (thinking…)
      • Visitors should be allowed in Daily Scrum

        Near the end of the "Daily Scrum" sections it says: "The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum."

        Change to: "The Daily Scrum is primarily an internal meeting for the Development Team. The Scrum Master may allow outside observers or participants, as long as they don’t disrupt the meeting"

        Rationale for replacing this paragraph: The team is responsible for doing their best to achieve the sprint goal, so it must be OK for them to involve external participants as they see fit. Teams rarely exist in isolation, they are part of a…

        127 votes
        Vote
        Sign in
        Check!
        (thinking…)
        Reset
        or sign in with
        • facebook
        • google
          Password icon
          I agree to the terms of service
          Signed in as (Sign out)
          You have left! (?) (thinking…)
        • Include Backlog Refinement in the Scrum Events section

          Backlog Refinement adheres to the definition of event (formal opportunity to inspect and adapt something.) Promoting it to event would make the guide tidier (presenting everything as a role/artifact/event,) facilitate the understanding and make it more difficult to forget it.
          But it would be needed to slightly change the description of event since it states that everything is time-boxed; refinement would be an exception to this rule.

          110 votes
          Vote
          Sign in
          Check!
          (thinking…)
          Reset
          or sign in with
          • facebook
          • google
            Password icon
            I agree to the terms of service
            Signed in as (Sign out)
            You have left! (?) (thinking…)
          • Drop the 3 questions from the Daily Scrum

            The Daily Scrum is about the team assessing their progress towards the Sprint Goal and planning their next 24 hours.
            While the 3 questions are a very common way of doing this, alternative approaches such as "walking the board" are also viable.
            Specifying that the 3 questions need to be answered in the Daily Scrum reduces the Dev Team's ability to self-organise and can produce arguments that other approaches are "not scrum".

            I'd like to either have the 3 questions made optional, adding an explanation that they are a common tool, but not the only choice, or drop them completely…

            106 votes
            Vote
            Sign in
            Check!
            (thinking…)
            Reset
            or sign in with
            • facebook
            • google
              Password icon
              I agree to the terms of service
              Signed in as (Sign out)
              You have left! (?) (thinking…)
            • Rename "Development Team" to "Delivery Team"

              In my opinion, there are at least three rationals for my suggestion. I look forward to your insights and thoughts about this suggestion.

              1.) The term "Development Team" fits well for software development teams - while term "Delivery Team" could also be appealing to other areas outside software development. For example we deliver trainings, we delivery hardware, we deliver marketing campains...

              2.) The members of a "Development Team" are often seen as "developers" - missing all the other roles that are necessary to create a shippable increment, such as testers, build and integration specialist, etc. Yes, we say the team…

              104 votes
              Vote
              Sign in
              Check!
              (thinking…)
              Reset
              or sign in with
              • facebook
              • google
                Password icon
                I agree to the terms of service
                Signed in as (Sign out)
                You have left! (?) (thinking…)
              • Remove "There are no exceptions to this rule"

                A sentence like "there are no exceptions to this rule" makes Scrum overly dogmatic, and keeps people stuck in Shu. The phrase shows up after "Scrum recognizes no titles for Development Team members other than Developer" and "Scrum recognizes no sub-teams in the Development Team". I've seen plenty of cases where exceptions to that rule (and other rules) make perfect sense. Please remove that sentence in both places where it shows up.

                103 votes
                Vote
                Sign in
                Check!
                (thinking…)
                Reset
                or sign in with
                • facebook
                • google
                  Password icon
                  I agree to the terms of service
                  Signed in as (Sign out)
                  You have left! (?) (thinking…)
                • Don't prescribe exactly when the sprint goal is set during sprint planning

                  Last paragraph of section "Topic One: What can be done this Sprint?" says: "After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. "

                  Change to: "During Sprint Planning, the Scrum Team also crafts a Sprint Goal."

                  Rationale for the change: No need to prescribe that the goal should be set AFTER deciding which PBIs to deliver. In many cases it will make sense to set the goal first, and then decide which PBIs make sense to achieve that goal. And that's even implied at the beginning of…

                  86 votes
                  Vote
                  Sign in
                  Check!
                  (thinking…)
                  Reset
                  or sign in with
                  • facebook
                  • google
                    Password icon
                    I agree to the terms of service
                    Signed in as (Sign out)
                    You have left! (?) (thinking…)
                  • Remove "Development Team isn’t allowed to act on what anyone else says"

                    At the end of "The Product Owner" section, it says: "No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says."
                    1) Change "tell" to "force" ("No one is allowed to *tell* the Development Team to work from a different set of requirement").
                    2) Remove "the Development Team isn’t allowed to act on what anyone else says".

                    Rationale: It's a self-organizing team, they judge for themselves how to best use their time, as long as they respect the sprint goal. When…

                    76 votes
                    Vote
                    Sign in
                    Check!
                    (thinking…)
                    Reset
                    or sign in with
                    • facebook
                    • google
                      Password icon
                      I agree to the terms of service
                      Signed in as (Sign out)
                      You have left! (?) (thinking…)
                    • Emphasize that releases can be more often than once a sprint!

                      I always encounter teams that practice Sprints as mini-waterfalls, with software being integrated and made release-ready only at the end of the Sprint, so that the increment is ready for the Sprint Review. They feel this is what Scrum asks for as this is what Scrum Guide describes. What I would like to see underscored in the next edition is that making releasable software available at the end of the sprint is just a minimal requirement and having it integrated & tested more often is encouraged even though not required.

                      57 votes
                      Vote
                      Sign in
                      Check!
                      (thinking…)
                      Reset
                      or sign in with
                      • facebook
                      • google
                        Password icon
                        I agree to the terms of service
                        Signed in as (Sign out)
                        You have left! (?) (thinking…)
                      • Introduce a Definition of Ready

                        The Definition of Ready is not as important as a Definition of Done. However, in order for the team to avoid "sprint planning hell", doing 'enough' product backlog refinement is crucial. Enough - is when there's 1-2 sprints of product backlog items in the (top of the) product backlog, that are deamed Ready.
                        I believe it helps teams to find a definition of what Ready is, so that it's clear what to do, and not do - and when to stop - when refining product backlog items.

                        55 votes
                        Vote
                        Sign in
                        Check!
                        (thinking…)
                        Reset
                        or sign in with
                        • facebook
                        • google
                          Password icon
                          I agree to the terms of service
                          Signed in as (Sign out)
                          You have left! (?) (thinking…)
                        • Clarify what the primary function of the Product Owner role is to avoid unintended proxies

                          Clarify what the primary function of the Product Owner role is to avoid unconscious proxies

                          Clarify: "The Product Owner is responsible for maximizing the value of the product and the work of the Development Team."

                          This sentence appears to skim over the primary function of the PO role in six words combined with a secondary, more tactical concern that mixes messages.

                          Suggest: "The Product Owner is a business decision making role responsible for maximizing the value of the product being developed using Scrum. At a tactical level, the Product Owner may seek to maximise the value of the Development Team's…

                          47 votes
                          Vote
                          Sign in
                          Check!
                          (thinking…)
                          Reset
                          or sign in with
                          • facebook
                          • google
                            Password icon
                            I agree to the terms of service
                            Signed in as (Sign out)
                            You have left! (?) (thinking…)
                          • Don't prescribe adding estimates to PBIs

                            Estimates should be optional - many Scrum teams are able to work without using story points, hours or T-shirt sizes. They simply count their stories per sprint and slice as small as possible. This may be under the topic of #NoEstimates, bur my suggestion is not say don't use estimates, but instead make it an optional practice. Similar to how using a burn down chart was mandatory in the past but now not. It should be simply a tool. Making it optional also enhances the self organising property of the team.

                            Proposal: remove "estimate" from the line: "Product Backlog items…

                            39 votes
                            Vote
                            Sign in
                            Check!
                            (thinking…)
                            Reset
                            or sign in with
                            • facebook
                            • google
                              Password icon
                              I agree to the terms of service
                              Signed in as (Sign out)
                              You have left! (?) (thinking…)
                            • Include the Definition of Done in the Scrum Artifacts section

                              The DoD adheres to the definition of artifact (work or value to provide transparency and opportunities for inspection and adaptation.) Promoting it to artifact would make the guide tidier (presenting everything as a role/artifact/event,) facilitate the understanding and make it more difficult to forget it.

                              38 votes
                              Vote
                              Sign in
                              Check!
                              (thinking…)
                              Reset
                              or sign in with
                              • facebook
                              • google
                                Password icon
                                I agree to the terms of service
                                Signed in as (Sign out)
                                You have left! (?) (thinking…)
                              • Publish an epub and mobi (Kindle) version of the guide

                                For ebook readers, pdf is not convenient, as it is a non-scaling format. Please make the Scrum Guide available for ebook readers (in my case the Kindle)

                                35 votes
                                Vote
                                Sign in
                                Check!
                                (thinking…)
                                Reset
                                or sign in with
                                • facebook
                                • google
                                  Password icon
                                  I agree to the terms of service
                                  Signed in as (Sign out)
                                  You have left! (?) (thinking…)
                                • Clarify the PO's role in maximizing the work of the Dev Team

                                  Current language: ""The Product Owner is responsible for maximizing the value of the product and the work of the Development Team."

                                  See: https://www.scrum.org/Forums/aft/1152#4917 for how this confuses people.

                                  If it were me, I'd probably say something like: "The Product Owner is responsible for guiding the Development Team through Sprint Goals, the Product Backlog, and other ways, to maximize the value of the product."

                                  I'm afraid that the current language implies that the PO is a Project Manager with accountability for all Scrum Team delivery, including controlling the Dev Team.

                                  25 votes
                                  Vote
                                  Sign in
                                  Check!
                                  (thinking…)
                                  Reset
                                  or sign in with
                                  • facebook
                                  • google
                                    Password icon
                                    I agree to the terms of service
                                    Signed in as (Sign out)
                                    You have left! (?) (thinking…)
                                  • Elevate the status of agreements in Scrum

                                    Core Scrum introduced the idea that the Definition of Done is not an artifact, but an agreement among the stakeholders, which can change (become robuster) over the course of development. There are other agreements in Scrum, for example the selected product backlog is the result of sequencing by the PO and the Dev Teams forecast of what it can accomplish. Or if the team cannot meet its forecast, it should fail on scope (deliver less than forecast), rather than do overtime or prolong the sprint.

                                    Other agreements are not core to scrum, serve to improve the performance of the team,…

                                    25 votes
                                    Vote
                                    Sign in
                                    Check!
                                    (thinking…)
                                    Reset
                                    or sign in with
                                    • facebook
                                    • google
                                      Password icon
                                      I agree to the terms of service
                                      Signed in as (Sign out)
                                      You have left! (?) (thinking…)
                                      1 comment  ·  Admin →
                                    • The length of time spent in meetings should be proportional to the Sprint

                                      2 days for 30 day sprint
                                      1 day for 2 weeks sprint
                                      1/2 day for 1 week sprint

                                      24 votes
                                      Vote
                                      Sign in
                                      Check!
                                      (thinking…)
                                      Reset
                                      or sign in with
                                      • facebook
                                      • google
                                        Password icon
                                        I agree to the terms of service
                                        Signed in as (Sign out)
                                        You have left! (?) (thinking…)
                                      • Like 'Commitment' changed to 'Forecast' can 'Estimate' change to 'Size'?

                                        First let me be clear, I'm not a fan of #NoEstimates. I see a lot of value in teams Estimating product backlog items. When size comes into play, they will find they do not all have the same perspective on the scope and complexity of the product backlog item.

                                        However often teams are not comfortable providing estimates because other parts of the organization are considering them as given planning.

                                        The word estimates has a historic meaning in waterfall projects, and is part of project management methods like Prince2 and PMI. Historically it is considered something you can and should get…

                                        23 votes
                                        Vote
                                        Sign in
                                        Check!
                                        (thinking…)
                                        Reset
                                        or sign in with
                                        • facebook
                                        • google
                                          Password icon
                                          I agree to the terms of service
                                          Signed in as (Sign out)
                                          You have left! (?) (thinking…)
                                          1 comment  ·  Admin →
                                        • Official Scrum Guide Logo

                                          Create a logo for download by anyone to promote the official scrum guide.

                                          23 votes
                                          Vote
                                          Sign in
                                          Check!
                                          (thinking…)
                                          Reset
                                          or sign in with
                                          • facebook
                                          • google
                                            Password icon
                                            I agree to the terms of service
                                            Signed in as (Sign out)
                                            You have left! (?) (thinking…)
                                            1 comment  ·  Admin →
                                          ← Previous 1 3 4 5
                                          • Don't see your idea?

                                          General

                                          Feedback and Knowledge Base