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

    148 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    17 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…

    273 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    completed  ·  28 comments  ·  Flag idea as inappropriate…  ·  Admin →
  3. 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…

    93 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    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

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

    20 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    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.

  5. Add a question to Daily Scrum: "Are we confident to complete the Full Sprint Backlog?"

    In addition to the three questions that favor transparency, we always ask ourselves this fourth one. If the answer is "yes" we do nothing. But if not, priorities may be reviewed, scopes may be redefined, etc. Important is that the team has a vision of where we are and given what is missing, if we are still confident on achieving the goal or need to make changes.

    7 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  Flag idea as inappropriate…  ·  Admin →
    completed  ·  Ken Schwaber responded

    We need a technique and maybe algorithm to determine HOW CONFIDENT we are.
    We could just look around, see how people are acting, or a million other tip-offs.

  6. Scrum values acronym - C-FORCE

    In my training on agile and scrum fundamentals, I usually put the values of scrum in this acronym - C-FORCE (Commitment above all, Focus, Openness, Respect, Courage, and with due respect to Ken and Jeff, I added Ethics on my own for my teams).
    Ethics is very important for teams that need to stick together and trust each other to self-organize and put team goals above all else.
    I have seen teams with an ethics deficit disintegrate very fast as it starts impacting and attacking every other value listed in scrum guide.

    15 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Flag idea as inappropriate…  ·  Admin →
    completed  ·  Ken Schwaber responded

    Commitment, Focus, Openness, Respect, Courage are all attributes that matter and can be detected in their presence or absence.

    Ethics is a matter of philosophy. Pretty soon we are into questioning what type of ethics are implied:

    “The choice between consequentialist and Kantian ethics is a difficult one, as there are many examples which are challenging to each sort of view. … According to the Kantian, what are really good or bad are not the consequences of our actions, but the actions themselves. So consider some bad actions, like acts of lying.”

    Ken

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

    67 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    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.

  8. 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
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    20 comments  ·  Flag idea as inappropriate…  ·  Admin →
  9. 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…

    159 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    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.”

  10. 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
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    8 comments  ·  Flag idea as inappropriate…  ·  Admin →
  11. 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.

    106 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    18 comments  ·  Flag idea as inappropriate…  ·  Admin →
  12. Business Analyst Role in Scrum

    Often it is seen that Product Owner get a supporting team member who will actually write User stories and process diagrams and finally PO is approving. Then in this case we must clearly mention what is expected from Business Analyst? Can BA be part of Development team?

    8 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  Flag idea as inappropriate…  ·  Admin →
    completed  ·  Ken Schwaber responded

    Scrum classes and consultants should have straightened this out for you.
    We do not have roles for the Development Team, just the skills needed to do this work and create done increments.
    The sum of the skills creates something and the PO judges whether it is worth the cost. Not by title, but by outcome.

  13. 32 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    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.

  14. 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
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    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.

  15. 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
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    20 comments  ·  Flag idea as inappropriate…  ·  Admin →
  16. one-to-one (face-to-face) retrospective meetings

    Yes I know there is no such meeting in Scrum. However I strongly recommend one-to-one (face-to-face) retrospective meetings
    in order to get more efficient feedback. In the guide document, as you know, one of the scrum master's responsibilities is to coach the team. So this kind of meeting would ease scrum master's job and scrum master would contact with team members in more healthy way. It can be arranged per one or two sprints with all team members individually.

    Of course it would be thought as a management meeting and out of scrum scope. But I think it is worth…

    10 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  Flag idea as inappropriate…  ·  Admin →
    completed  ·  Ken Schwaber responded

    We authorize you to add these meetings to your culture and organization. However, they are not Scrum.

    I like the idea of going for a walk to talk something over, but I’m not adding it to Scrum.

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

    35 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    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.

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

    32 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    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

  19. 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
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    42 comments  ·  Flag idea as inappropriate…  ·  Admin →
  20. 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.

    170 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    22 comments  ·  Flag idea as inappropriate…  ·  Admin →
← Previous 1
  • Don't see your idea?

General

Feedback and Knowledge Base