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. Change "if appropriate and not in conflict with product or organizational standards."

    In the Sprint Retrospective section of the Scrum Guide it says "During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of "Done", if appropriate and not in conflict with product or organizational standards."

    I feel that the words "if appropriate and not in conflict with product or organizational standards." are driven by corporate bureaucracy thinking and pressures from corporates on Scrum.

    What happens if those "standards" are the essence of what is destroying Scrum? If those standards are the things that are impeding the team, surely they should…

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

    We’ll send you updates on this idea

    hold  ·  1 comment  ·  Flag idea as inappropriate…  ·  Admin →
  2. Why Sprint Goal inspection at least monthly?

    When we read (in the section Sprint) that “Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month.” it simply says to us that the progress toward a Sprint Goal is inspected/adapted at least monthly. However, we know that on a daily basis the same is done in the Daily Scrum event: “The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal”. As a result, these two may look mutually contradicting. Suggest correct the first one.

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

    We’ll send you updates on this idea

    hold  ·  1 comment  ·  Flag idea as inappropriate…  ·  Admin →
  3. Introduce the concept for non IT systems to use Scrum

    For now it very focused on building complex products. However, based on the framework best practices how it can used for non IT industries can be a good starting point.

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

    We’ll send you updates on this idea

    hold  ·  0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  4. Clarify identification with Team and Sprint Goal in Daily Scrum questions

    Adapt the 'Three Questions' in Daily Scrum to make things clearer:

    • What did I do yesterday that helped my team meet our Sprint Goal?
    • What will I do today to help my team meet our Sprint Goal?
    • Do I see any impediment that prevents me or my team from meeting our Sprint Goal?

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

    We’ll send you updates on this idea

    hold  ·  0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  5. add a section for well known and proven practices that support the application of Scrum

    The Scrum Guide is not very specific about what tools can be used to support your Scrum implementation. I guess there are a few well known and proven practices out there like story points, velocity, DoR, and many more.

    I think it would be great, if the guide would provide some hints on the proven practices to provide guidance for the individual Scrum implementation. Please state as well, that those practices have proven to be helpful for a lot of people, but that does not automatically mean they will work for you.

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

    We’ll send you updates on this idea

    hold  ·  1 comment  ·  Flag idea as inappropriate…  ·  Admin →
  6. Add Learning as a Scrum value

    The lifeblood of Scrum are the Scrum values and they are critical to the success of Scrum. The lacking value is is that of Learning. As a value one can say

    Learning Scrum, agile and other practices
    Learning to work as self-organising team
    Learning other peoples views in conversations and events
    Learning ways to plan the sprint in Sprint Planning
    Learning better ways to plan then next 24 hours in Daily Scrums
    Learning to create better products increments during the sprint
    Learning from feedback during Sprint Review
    Learning new ways in Sprint Retrospect

    Learning enhances every other Scrum value, for…

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

    We’ll send you updates on this idea

    hold  ·  0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  7. A wrong backlog name used in Cancelling a Sprint

    It is in the chapter "Cancelling a Sprint":
    All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog.

    Here should be:
    All incomplete Sprint Backlog Items are re-estimated and put back on the Product Backlog.

    p/s
    To re-estimate all incomplete Product Backlog Items looks like a huge job which does not have a big sense for a Sprint Cancelation. To re-estimate Sprint Backlog will be enough.

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

    We’ll send you updates on this idea

    hold  ·  1 comment  ·  Flag idea as inappropriate…  ·  Admin →
  8. Consistently capitalize the words "Increment" and "Increments"

    The Increment is the only artifact that isn't consistently capitalized in the Scrum Guide (i.e., it appears sometimes as "Increment" and other times as "increment"). (Note that this is an issue for the plural form too.)

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

    We’ll send you updates on this idea

    hold  ·  0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  9. Scrum Master is not only a servant leader for the Scrum Team

    Scrum Guide says: The Scrum Master is a servant-leader for the Scrum Team.

    Proposed change: The Scrum Master is a servant-leader for the Scrum Team and the whole organisation.

    Rationale: for the Scrum Team to be able to deliver and work effectively, the Scrum Master can not just serve the Scrum Team in isolation. The Scrum Master needs to spend his time serving others outside of the Scrum Team too. Changing this will also make many Scrum Masters who is only focused serving the Scrum Team to think that others outside of the Scrum Team need to be served too…

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

    We’ll send you updates on this idea

    hold  ·  0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  10. Scrum Master service to the Scrum Team

    Suggestion: add one more section "Scrum Master service to the Scrum Team"

    There are some items in "Scrum Master service to the Product Owner" that should belong in "Scrum Master service to the Scrum Team".

    - Helping the Scrum Team understand the need for clear and concise Product Backlog items;
    - Understanding and practicing agility; and,
    - Facilitating Scrum events as requested or needed.
    Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;

    It does not make sense to put these items under "Scrum Master service to the Product Owner"…

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

    We’ll send you updates on this idea

    hold  ·  1 comment  ·  Flag idea as inappropriate…  ·  Admin →
  11. Add a paragraph break between 2 logically distinct topics in the Definition of "Done" section

    The 2nd paragraph in the section on the Definition of "Done" is somewhat long and contains 2 logically distinct topics. Below is the current text followed by the proposed text with added paragraph break where I think it would be helpful:

    CURRENT TEXT:

    The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done.” Development Teams deliver an Increment of product functionality every Sprint. This Increment is…

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

    We’ll send you updates on this idea

    hold  ·  0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  12. Fix typo and revise wording for: “Fewer than three Development Team members decrease interaction and results in smaller productivity gains.”

    There is a typo in the statement: “Fewer than three Development Team members decrease interaction and results in smaller productivity gains.” Instead of “decrease” it should say “decreases.”
    I think it also would be slightly clearer to start the sentence with “Having”, i.e.: “Having fewer than three Development Team members decreases interaction and results in smaller productivity gains.”

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

    We’ll send you updates on this idea

    hold  ·  0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  13. Replace the word "framework" by "method" in the very first sentence of the guide.

    The word framework implies, that you first have to insatiate it, before you can use it. While this is formally true on an absolute scale, a big advantage of Scrum (and maybe even one of the major reasons for its success) is, that it is much more ready to use, when compared to, e.g., RUP or most other agile methods.

    Using the word "method" instead may also reduce the danger of Scrum being too much and too often adapted by unexperienced teams.

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

    We’ll send you updates on this idea

    hold  ·  0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  14. Improve readibility by removing "he or she" when talking about PO

    When talking about Scrum Master "he or she" is not used. If gender is an important issue you could add a section about why using just male form as used often in books to improve readibility of the descriptive text.

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

    We’ll send you updates on this idea

    hold  ·  0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  15. Clarify whether the ScrumMaster is active in development or not

    Conflicting opinions have been expressed (both in our team and in Scrum Alliance articles) as to whether the ScrumMaster is also active in development (e.g. in writing code). It would be useful to have a clear answer (yes, no, unspecified) so that we can stop discussing what Scrum is and get down to whether it is true-Scrum that we want or something resembling it.

    https://www.scrumalliance.org/community/articles/2013/february/the-case-for-a-technical-scrummaster

    https://www.scrumalliance.org/community/articles/2013/december/playing-the-scrummaster-role

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

    We’ll send you updates on this idea

    hold  ·  2 comments  ·  Flag idea as inappropriate…  ·  Admin →
  16. Documentation in Scrum

    What all documentation can be done as part of Scrum? Like Design documentation, Requirement design documents..

    We must have a some guidance from Scrum Guide on this.

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

    We’ll send you updates on this idea

    hold  ·  5 comments  ·  Flag idea as inappropriate…  ·  Admin →
  17. clarify the "Scrum Master Service to the Product Owner" section

    It is not clear who the "target" of individual activities is in this section ("service to the development team" is much clearer). For example, should the SM or the PM understand product planning in an empirical environment. Should "helping the Scrum Team understand the need for clear and concise product backlog items" read "helping the Product Owner understand..."?

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

    We’ll send you updates on this idea

    hold  ·  1 comment  ·  Flag idea as inappropriate…  ·  Admin →
  18. Clarify optional participants of Daily Scrum

    When I read the Scrum Guide last time I got a bit confused, because I read "The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum.". So strictly speaking even the Scrum Master himself could not participate. I think the German version is more precise because it talks about "active participation". Maybe this is misleading especially for foreign speakers.

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

    We’ll send you updates on this idea

    hold  ·  1 comment  ·  Flag idea as inappropriate…  ·  Admin →
  19. Why we plan for next 24 hours in daily scrum?

    In Daily Scrum, more precisely, plan should be for next 8 or 9 working hours and not for 24 hours.

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

    We’ll send you updates on this idea

    hold  ·  2 comments  ·  Flag idea as inappropriate…  ·  Admin →
  20. Change ideal team team size back to 7 +/2

    The latest scrumguide recommends ideal dev. team size is 6 +/- 3 or 3 to 9. Sure, I understand there are plenty successful teams with less than 5 members, but overall I think it is too small.

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

    We’ll send you updates on this idea

    hold  ·  3 comments  ·  Flag idea as inappropriate…  ·  Admin →

General

Feedback and Knowledge Base