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.

    232 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…)
    • Add the 5 Scrum Values to the Scrum Guide

      The five values are incredibly important to understanding the ethos of good Scrum teams and organizations yet are not included in the Scrum Guide. This seems like a significant omission to me.

      222 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…

        159 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").

          156 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.

            109 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…

              81 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.

                69 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 see your idea?

                General

                Feedback and Knowledge Base