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 Definition of Ready to Scrum guide

    Ready has been emphasized in the 2013 Scrum Guide update and we need to emphasize it further.

    1 vote
    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 →
  2. add some recommendations for the daily scrum - using a timer fixed to a holder on the scrum board

    Fixing the timer on the scrumboard so that everybody in the team can see the time one is allowed to speak has different advantages:
    - the speaker can move cards free hand
    - listeners don't get nervous if they think somebody talks too long, they see and know if somebody has the right to speak
    - the speaker also can see the time and can speed up etc

    I think the aim of having the daily scrum timeboxed but still all people in the team could tell their status is easier to reach if you use such a timer and…

    1 vote
    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. Alternative less dogmatic scrum

    Developing software is hard and requires much critical thought and analysis of the problem.

    Another massive problem is the outside world expecting predictions about when something will be done and how much it will cost. The 'lets just start and see where we end up' model is so much better. They don't understand such predictions are always lies and are shocked when something goes over budget or takes more time.

    But people always want to avoid facing the hard problems. It seems Scrum has become very rigid to force them to face those problems. Even though dogma's don't actually work…

    1 vote
    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 →
  4. 1 vote
    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 →
  5. 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 →
  6. Use examples along with the theory to clarify the concepts.

    It would be nice to clearly understand the different concepts illustrated in the Scrum guide through giving examples from real-life experiences gained while implementing Scrum.

    3 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 →
  7. Keep it simple

    Keep it as simple as possible.

    3 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 →
  8. Retrospectives should not be about individual people

    The Sprint Retrospective section says (July 2013):

    "Inspect how the last Sprint went with regards to people, relationships, process, and tools"

    From a humanistic / servant-leader / Deming perspective, I feel "people" is not a good word to use here, since it can easily be misunderstood or misconstrued. "Relationships" probably already covers the associated issues.

    But if we want to discuss people issues explicitly here (rather than out-of-band), then I would hesitantly suggest "behaviours" as a replacement. And I would put it last, not first.

    [Aside: When articulating such a Retrospective list, I usually also call out "policies" explicitly. Although,…

    1 vote
    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 →
  9. 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 →
  10. 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 →
  11. Change the term "Backlog Refinement" to "Sprint Lookahead"

    I realize that this term has just changed in the last version of the Scrum Guide, and is an improvement over the previous term used (grooming). However, with new teams, one of the frequently asked questions (and sometimes misinterpretation) is that the "Backlog Refinement" is an activity that the PO should do alone, in isolation. Changing the title to "Sprint Lookahead" communicates the idea that this is an activity for the entire Scrum Team, and that this is an opportunity to "Plan Ahead", for future Sprint(s).

    1 vote
    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. 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 →
  13. Clarify what "all" means wrt to making the PBL transparent to "all"

    Is this "all in the world"? "all" in the organization? "all" in the universe?

    Idea brought on by (likely) Shu level read of the guide, and I assume that the primary target audience of the SG is Shu.

    Here is the discussion:
    https://www.scrum.org/Forums/aft/1139#4899

    My guess is "all" was intended to be "Scrum Team and stakeholders"

    9 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 →
  14. SCRUM has two different types of retrospective

    We found our retrospectives only skimmed the surface of our our issues where so we did a retrospective that looked at what our principles should be for our Scrum team we discovered some deep niggly interteam problems that infact were easily solved once we identified them. We has a session in three parts: theoretical review of the SCRUM guide (avoiding discussions about how we do it) while at the same time people noted themes and issues on postis, then we grouped our postits into the themes and for each wrote down problems and solutions, then we summarised it in a…

    1 vote
    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. 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 →
  16. 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,…

    17 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 →
  17. Allow released features to be part of the increment

    It should be possible to have released (into production) be reviewed during the Sprint Review. Currently the Scrum Guide mentions that the development team delivers "a potentially releasable Increment", which might get people confused. This could indeed be understood that the increment can only be put into production when the Sprint is finished, so after the Sprint Review.
    In order to change this, I suggest to use the following: "deliver a potentially releasable or released Increment".

    5 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 →
  18. Include the Sprint Goal in the Scrum Artifacts section

    The Sprint Goal 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.

    10 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. Merge the Sprint Review & Retrospective to a single meeting

    Let teams decide how much time that they spend on each one.

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

    We’ll send you updates on this idea

    hold  ·  9 comments  ·  Flag idea as inappropriate…  ·  Admin →
1 2 3 4 5 6 8 Next →

General

Categories

Feedback and Knowledge Base