General

User Voice

The Scrum Guide is a community website, created and maintained by Jeff Sutherland and Ken Schwaber. Via this User Voice forum, you may propose changes to the website, the Scrum Guide itself, or engage in discussion about suggestions others have made. This User Voice is read and supported by the Scrum Guide creators.

Periodic reviews of these suggestions inform the product backlog for the Scrum Guide, but final decisions on changes and functionality are Ken and Jeff's.

User Voice is read-only while new Scrum Guide is under development

User Voice is in read-only mode while Jeff and Ken create the next release, based on your suggestions in the User Voice, input from the overall Scrum community, and to meet advanced applications of Scrum that are either being made or have been requested.


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

    113 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    42 comments  ·  Flag idea as inappropriate…  ·  Admin →
  2. Remove "Remove Impediments" as a responsibility of the Scrum Master

    The "Remove Impediments" responsibility of the Scrum Master is much too generic. It is easy to formulate everything as an impediment. It also leads to the Development Team not taking responsibility for solving their own problems but instead assign it to the Scrum Master because his role is to remove impediments.

    Suggestions:
    - Remove "remove impediments" completely, or
    - Add "remove impediments" also to the PO and Dev Team responsibility, or
    - Clarify the kinds of impediments are suggested, perhaps by adding an additional clarification such as "impediments that the team cannot yet resolve themselves or that do not directly…

    108 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    completed  ·  28 comments  ·  Flag idea as inappropriate…  ·  Admin →
  3. 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").

    100 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    20 comments  ·  Flag idea as inappropriate…  ·  Admin →
  4. 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…

    100 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    33 comments  ·  Flag idea as inappropriate…  ·  Admin →
    completed  ·  Ken Schwaber responded

    The Scrum Guide addresses this clearly: “only Development Team members participate in the Daily Scrum.”

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

    92 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    22 comments  ·  Flag idea as inappropriate…  ·  Admin →
  6. 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…

    83 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    20 comments  ·  Flag idea as inappropriate…  ·  Admin →
  7. 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.

    65 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    18 comments  ·  Flag idea as inappropriate…  ·  Admin →
  8. Rename "Development Team" to "Team" and remove "Scrum Team"

    Proposal:


    • Rename "Development Team" to "Team"

    • Remove "Scrum Team" and replace the references of Scrum Team to "Team, PO, and SM"

    The purpose of this proposal is:


    • Resolving the naming problem of "development team" (as Delivery Team is a terrible alternative),

    • Removing a small difference in terminology between Scrum and LeSS.


    59 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    17 comments  ·  Flag idea as inappropriate…  ·  Admin →
  9. 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…

    55 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    8 comments  ·  Flag idea as inappropriate…  ·  Admin →
  10. 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.

    46 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    6 comments  ·  Flag idea as inappropriate…  ·  Admin →
    completed  ·  Ken Schwaber responded

    If you like “tidier” guides, what are you doing in the field of development?

    Read my blog entry on my Wordpress about the Scrum Development Kit (SDK)
    and you will see the problem.
    For instance, Done should list the artifacts created, their syntax, and the tool where they are stored and updated.

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

    45 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    9 comments  ·  Flag idea as inappropriate…  ·  Admin →
  12. Slightly change the Scrum Roles definitions to avoid newcomer confusion

    Newcomers have a hard time with two particular aspects of the definitions of the 3 roles: 1) the word "team" is used twice and that confuses people; 2) the word "developer" turns off a lot of non-coders.

    I would suggest wording along these lines:

    "A Scrum Team has a ScrumMaster, Product Owner and 3-9 other team members who have all the skills necessary to create a potentially releasable product increment every Sprint."

    That way the word "team" is only used once. We get rid of the "developer" word that turns off non-coders. We make it clear the rest of the…

    43 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    21 comments  ·  Flag idea as inappropriate…  ·  Admin →
    completed  ·  Ken Schwaber responded

    The topic of naming things in Scrum has 27 years of history.
    When we look efforts that use Scrum, we find people bend some of the names to fit their culture. Sometimes just to “brand” it as their own.
    All fine:
    Just remember empiricism, lean, inspect and adapt, self-organizing teams, and the values.

    In the meantime, if you are bored or want to be noticed, don’t fiddle around with Scrum. Go for a run.

    Ken

  13. 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)

    36 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    8 comments  ·  Flag idea as inappropriate…  ·  Admin →
  14. 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…

    31 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    8 comments  ·  Flag idea as inappropriate…  ·  Admin →
    completed  ·  Ken Schwaber responded

    FIRST – Scrum is for researching, creating, developing, delivering, etc of PRODUCTS. Not Projects. PMI needs to change the meaning of “P”.

    The “manner” of making an estimate is optional.
    When we order the product backlog, the amount of effort we believe is required becomes an “estimate.” It frequently changes as more is learned, including decomposition.

    When I read the comments, I see many techniques for people managing their product backlog. All are good unless they are useless impediments. If not useless impediments, leave them alone.

  15. Make the Product Vision part of Scrum

    The Product Vision is essential to set a common goal and direction for the Scrum teams and stakeholders. It helps to identify the scope and set priorities during the development. Developing a Product Vision fills the initial Product Backlog and thus focusses on the "fuzzy front end" that is otherwise not considered in Scrum.

    24 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  Flag idea as inappropriate…  ·  Admin →
    completed  ·  Ken Schwaber responded

    We’ve worked on extensions to Scrum for UX and Leadership.

    If a Product Manager (Owner) isn’t very good at managing their product, we need a whole new field of study, course work, and assessments. Even more, we need to replace the person before he/she demoralizes the team and ruins the product/organization.

    Just asking them to do one part of their job (Vision) without addressing everything else is inadequate.

    So many people, so few really good product managers, product owners.

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

    19 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    6 comments  ·  Flag idea as inappropriate…  ·  Admin →
    completed  ·  Ken Schwaber responded

    The word “confusing” is used. Does that mean that Scrum is not absolutely, incredible clear to everyone who uses it for whatever purpose. That would mean that Scrum is structured to address complex problems what many possible solutions are present.

    The Scrum Team’s job, led by the Product Owner and guided by the Scrum Master, is to arrive at the best approach for their product. Who knows, maybe the whole team or organization will participate in this definition of their culture.

    Read about Spotify and Salesforce.com.

    Ken

  17. 18 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  Flag idea as inappropriate…  ·  Admin →
    completed  ·  Ken Schwaber responded

    At one point, we only said that it had to be “releasable.” This was interpreted to mean that it had to be released. Then everyone wanted us to define who it had to be released to:
    - was this a technical release into the technology
    or
    - was this a release to customers/users that started using it.

    So, we changed the phrase to “potentially releasable”

    The application of Scrum to advanced research problems where most of the progress is in understanding and maybe a published paper based on research really makes this phrase difficult.

    But, we never said that Scrum was easy. We did say that you should know your domain and that intelligence and teamwork helped a lot, however.

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

    14 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  Flag idea as inappropriate…  ·  Admin →
    completed  ·  Ken Schwaber responded

    Those are interesting guidelines. Based on where we are in creating a product, the skills and background of the team members, and the response of the customers/users, you will find this ratio shifting all over the place. Adjustments occur as the context demands.

    Unless you want a methodology, then we can pour concrete on ratios.

  19. Change "Removing impediments to the Development Team’s progress" to "Helps the team to remove impediments to their progress"

    I believe the role of the Scrum Master is to help a team to resolve their own problems and not to be seen as the only person who can fix impediments. I have worked with teams that have stated that it is not their responsibility to fix problems as the Scrum Guide says that is the role of the Scrum Master.

    11 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Flag idea as inappropriate…  ·  Admin →
    completed  ·  Ken Schwaber responded

    We were pleased to see that you were valuable, getting to explain to the Scrum team how impediments are identified and removed.

    Most organizations have techniques for identifying and resolving impediments found in Scrum. Test the efficacy by maintaining a “parking lot” of impediments.

  20. Change label of "Sprint" to "Hike", or a word that suggest something less hectic.

    The word "Sprint" suggests a hectic time within a Sprint timebox.

    1

    We coach teams to act professionally, slice work into smaller pieces and work with sustainable pace towards the Sprint goal. This contradicts with 'sprinting'.

    2

    For people outside of a Scrum Team it sends the message of busyness.

    9 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Flag idea as inappropriate…  ·  Admin →
    completed  ·  Ken Schwaber responded

    Scrum is formally translated into over 30 languages, and used in many more cultures.

    Don’t try to wordsmith. In the United States, “hikes” start the play in football and a creators of chaos. Much more chaotic than formally structured “Sprints” with start/end and formal lines.

← Previous 1

General

Categories

Feedback and Knowledge Base