What do you think about the revision changes of Scrum Guide 2017

Last post 11:08 pm January 1, 2019
by Gulistan Fatima
29 replies
Author
Messages
05:22 pm November 7, 2017
  1. Added section on the Uses of Scrum:

    Scrum was initially developed for managing and developing products. Starting in the early 1990s, Scrum has been used extensively, worldwide, to:

    1. Research and identify viable markets, technologies, and product capabilities;
    2. Develop products and enhancements;
    3. Release products and enhancements, as frequently as many times per day;
    4. Develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use; and,
    5. Sustain and renew products.

    Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.

    As technology, market, and environmental complexities and their interactions have rapidly increased, Scrum’s utility in dealing with complexity is proven daily. Scrum proved especially effective in iterative and incremental knowledge transfer. Scrum is now widely used for products, services, and the management of the parent organization. The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive. These strengths continue operating in single, several, many, and networks of teams that develop, release, operate and sustain the work and work products of thousands of people. They collaborate and interoperate through sophisticated development architectures and target release environments.

    When the words “develop” and “development” are used in the Scrum Guide, they refer to complex work, such as those types identified above.

  2. Changed wording in The Scrum Master section to provide better clarity to the role. The text now reads:

    The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

    The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

  3. Added to the section Scrum Master Service to the Product Owner

    Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible.

  4. Updated the first paragraph of the Daily Scrum section to read:

    The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.

  5. Updated the Daily Scrum section to provide clarity on the goals of the Daily Scrum including this text:

    The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used:

    • What did I do yesterday that helped the Development Team meet the Sprint Goal?
    • What will I do today to help the Development Team meet the Sprint Goal?
    • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
  6. Added clarity around time-boxes

    Using the words “at most” to remove any questions that the time-box for Events means maximum length, but could be shorter.

  7. Added to the Sprint Backlog section:

    To ensure continuous improvement, it includes at least one high priority way in which the team works, identified in the previous Retrospective meeting.

  8. Added clarity to the Increment section:

    An increment is a body of inspectable, "Done"" work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal.

06:51 pm November 7, 2017

I'm happy with all of them.  The one that stands out to me is, probably predictably: 

Added to the Sprint Backlog section:

To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.

As Ken Schwaber said, there's a risk of this being prescriptive and telling the Development Team how to plan their work.  I understand it, it's just a little... uncomfortable?

 

12:39 am November 8, 2017

Every prescription risks constraining Scrum, and making it less generally applicable and less useful in the hands of skilled teams. Adding retrospective process improvement items to the Sprint Backlog has, of course, always been a quite sensible option. The major constraint against this practice being taken up, in my experience, has so far been tooling. Some electronic Scrum boards may not support the planning of work unless it corresponds to Product Backlog items.

This has had the effect of shaping peoples thinking and creating assumptions about how Sprint Backlogs ought to be formed. I have no firm opinion about this change to the Guide one way or the other. Certainly the Scrum Guide is subject to inspection and adaptation by Ken and Jeff, and they should not be afraid to experiment. Personally, I hope that this new addition encourages tool vendors to step up to the mark, improve their products, and give teams greater freedom and discretion in the planning of their work.

01:12 am November 8, 2017

One interesting change, which is not mentioned in the list of changes, regards the Product Backlog:

2016 version: "The Product Backlog is an ordered list of everything that might be needed in the product"

2017 version: "The Product Backlog is an ordered list of everything that is known to be needed in the product"

 

08:53 am November 8, 2017

I spotted a few other interesting changes that aren't mentioned:

 

Clarification about who can attend the Daily Scrum. I think that previously, use of the word 'participate' confused matters.

2016 version: "The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum."

2017 version: The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting."

 

 

A new line added about how an expanded Definition of Done may cause increments that were previously Done, to no longer be Done, because they don't meet the new expanded DoD.

"New definitions, as used, may uncover work to be done in previously “Done” increments." 

I'm curious as to how this should be handled? Should the Product Backlog Items from the existing increment be re-added to the Backlog so they can be inspected and adapted to meet the new DoD?

09:52 am November 8, 2017

@Ian

2017 version: "The Product Backlog is an ordered list of everything that is known to be needed in the product“

    I wonder why this wasn't mentioned. To me, this is a very important and major change, that I am very happy about. It helps ensuring that the product backlog is only containing items of which everybody can be sure they are considered to be done at the current moment, while the previous wording allowed to throw just all kind of ideas and maybes into the backlog. This often ended up in a backlog full of "might be done" items, causing problems for the team to refine and plan efficiently, if the PO isn't always available.

    @Duncan

    2017 version: The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting."

    Great change. Even it doesn't change much about how the daily scrum is done, it sorts out ongoing rise of questions about "attend" vs. "participate".

    As for the rest of the changes, I agree with Alex that the most interesting change is the one to the Sprint Backlog, while I'm not sure yet what to think about it, as it enforces something quite specific. Also not sure how to interpret "process" exactly. Is human behavior and mindset part of the process? Cause in many cases, having people retrospect and rethink these topics is sometimes more helpful than doing the same for the process. Individuals and interactions over processes and tools.

    10:24 am November 8, 2017

    It helps ensuring that the product backlog is only containing items of which everybody can be sure they are considered to be done at the current moment, while the previous wording allowed to throw just all kind of ideas and maybes into the backlog.

    Good. I was rather worried by this change, on the grounds that it might lead to the impression that requirements must somehow be “known” up-front. I’m glad to see that it is being viewed in terms of what is thought to be known at the current moment.

    10:31 am November 8, 2017

    I'm curious as to how this should be handled? Should the Product Backlog Items from the existing increment be re-added to the Backlog so they can be inspected and adapted to meet the new DoD?

    My advice is to see this as new work and new PBIs such as new user stories, rather than as work which has somehow become undone. This is a point I tried to make in a recent blog post: don’t bring user stories back from the grave.

    01:27 pm November 8, 2017

    @Steven Busse

    Great change. Even it doesn't change much about how the daily scrum is done, it sorts out ongoing rise of questions about "attend" vs. "participate".

    Do you think it does, though? I'm worried it might now be a case of 'we're not really disrupting the meeting by participating'... Does this mean that, technically, those outside the Dev Team can now participate, if they're contributing to the Dev Teams' 24h plan?

    02:44 pm November 8, 2017

    So does this mean the PSM 1 test has changed?  I am wrapping up my studying to take the assessment soon.

    Thanks,

    07:27 am November 9, 2017

    Does this mean that, technically, those outside the Dev Team can now participate, if they're contributing to the Dev Teams' 24h plan?

    The Scrum Guide still says the meeting is internal to the Development Team. So no, I don't think it does mean that.

    Personally, I was thrilled to see the change to the Sprint Backlog. In Essence it is what my team was already doing, implementing what Sutherland calls the "Scrumming the Scrum" pattern. In that pattern a Kaizen PBI was created as the result of the retrospective and was put on the backlog as the highest priority item, so it would be pulled into the next sprint. Obviously, this required the Product Owner's consent to continually add these items to the top of the backlog.

    I like this new way better, because the Kaizen moves right into the Sprint Backlog where it belongs anyway and it requires no additional consent from the PO.

    I'm curious to see where the changes to the ScrumMaster role will take us.

    10:26 am November 9, 2017

    But wait, there's more... :-)

     

    The very first sentence also has an undocumented change:

    2016: Scrum is a framework for developing and sustaining complex products
    2017: Scrum is a framework for developing, delivering and sustaining complex products

    Not a big deal, I suppose, seeing as most of us are already delivering. But it's a nice addition for clarity's sake.

     

    Also, a little further down on page 3 in the "Definition of Scrum" section:

    2016: Scrum makes clear the relative efficacy of your product management and development practices so that you can improve.
    2017: Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.

    Again, clarity (what is improved) and a statement that improvement is continuous.

     

    The section on the Scrum Team has had a sentence added: The Scrum Team has proven itself to be increasingly effective for all the earlier stated uses, and any complex work. Referring back to the new section on the uses of Scrum.

     

    Changes to the role of PO:

    2016: 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.
    2017: No one can force the Development Team to work from a different set of requirements.

    This one is a little tricky, because it sounds as if the Development Team has the authority to overrule the Product Backlog as the source of requirements? That's probably not what they meant, though.

     

    Changes to the role of Dev Team:

    The sentence A “Done” increment is required at the Sprint Review. was added.

    2016: Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
    2017: Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;

     

    Changes to Sprint Planning:
    2016: After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal.
    2017: During Sprint Planning the Scrum Team also crafts a Sprint Goal.

     

    Changes to the Sprint Retrospective
    The following sentence was added: The Scrum Master ensures that the meeting is positive and productive.

    2016: During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the definition of “Done” as appropriate.
    2017: 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.

    Changes to the Product Backlog:

    Product Backlog items often include test descriptions that will prove its completeness when “Done.” was added

    03:22 pm November 9, 2017

    Why would these not be included in the revisions page?

    07:58 am November 13, 2017

    Why indeed :-)

    12:48 am November 14, 2017

    I am seeking to understand a bit better the new phrase in 'Sprint Backlog' "To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting."

    - is a team-specific process improvement in view here?  - an improvement that is (more or less) within the team's control?  Or could this be a wider company process improvement (which would of course more difficult for a single team to implement)

    Thoughts?

    02:48 pm November 14, 2017

    If a Sprint Retrospective is conducted well, would the Scrum Team identify and seek to implement actions which are not sufficiently under their control?

    07:36 pm November 14, 2017

    They could seek to implement actions to address an issue they only influence.  

    02:09 pm November 15, 2017

    Highlighting that the framework can be applied beyond software is a nice addition.
    The additional information and rewording for the Scrum Master role will be helpful to some.
    Daily Scrum changes are a great step in a positive direction. Promoting a conversation over the three question format (3QF) or walking the board has been a challenging sell even to PSTs.
    The need to further reiterate the definition of a time-box highlights one of many symptoms exemplifying that Scrum, for many, is not "Simple to understand" as advertised. :-)

    The requirement to have "at least one high priority process improvement identified in the previous Retrospective meeting" on the Sprint Backlog creates some issues as it does not align with the definition of the Sprint Backlog.
    It is not a Product Backlog Item (PBI).
    It is not a part of the plan for delivering the Increment and realizing the Sprint Goal.
    It is not a forecast of functionality.

    The Sprint Backlog belongs solely to the Development Team therefore so would this process improvement item.
    Changes are inspected and adapted during the Daily Scrum (for Development Team only).
    Development Team works through the plan.
    Only the Development Team can change its Sprint Backlog during a Sprint.
    It is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint.

    I also find the change from "The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum." to "The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting." problematic as it interferes with self-organization. It was already difficult enough to keep many organizations from using it as a traditional status update meeting. Transparency is a pillar but the information discussed during the Daily Scrum should generally have no impact on anybody else. If it does, then it is the Development Team's responsibility to raise the concerns and issues.

    02:42 pm November 15, 2017

    The requirement to have "at least one high priority process improvement identified in the previous Retrospective meeting" on the Sprint Backlog creates some issues as it does not align with the definition of the Sprint Backlog.
    It is not a Product Backlog Item (PBI).
    It is not a part of the plan for delivering the Increment and realizing the Sprint Goal.
    It is not a forecast of functionality.

    The Sprint Backlog belongs solely to the Development Team therefore so would this process improvement item.
    Changes are inspected and adapted during the Daily Scrum (for Development Team only).
    Development Team works through the plan.
    Only the Development Team can change its Sprint Backlog during a Sprint.
    It is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint.

    I do kind of agree with this actually.  I understand they wanted to ensure teams are continuously improving, but it does feel as if this is a slightly awkward way of doing it. 

    Is this also, slightly, implying that the Retrospective and continuous improvement only applies to the Development Team?  If not, then do we really want Scrum Team work on the Development Team's Backlog?

    03:50 pm November 15, 2017

    If a certain process improvement is disjoint to the delivery needs of the next Sprint, then it may be hard to make the case that it is “high priority”. Process changes are not made in isolation of empirical value delivery considerations, and improvements ought to be made in a timely and considered way that maximizes the value delivered each Sprint.

    Retrospective analysis should apply to the whole Scrum Team (or Nexus). However it is reasonable for Development Teams to take ownership of specific improvement objectives (or portions thereof) which they consider to be valuable and achievable. The new guidance is, essentially, to make these visible in the Sprint plan.

    Not all actions from a Retrospective necessarily fall to a Development Team to implement. For example a Product Owner may take away certain actions which he or she prioritizes in order to help maximize value delivery, but those actions would not necessarily be planned into the Development Team’s Sprint Backlog.

    04:06 pm November 15, 2017

    Ian, completely agree, however, why is there less emphasis on the Product Owner's continuous improvement? Why less emphasis on the Scrum Master? Why less on the Scrum Team as a whole?

    04:20 pm November 15, 2017

    Probably for no greater reason than the framework is minimally prescriptive. The Sprint Backlog is prescribed, and effectively owned by the Development Team.

    04:43 pm November 15, 2017

    Not all actions from a Retrospective necessarily fall to a Development Team to implement. For example a Product Owner may take away certain actions which he or she prioritizes in order to help maximize value delivery, but those actions would not necessarily be planned into the Development Team’s Sprint Backlog.

    This highlights the issue that I raise regarding this change.  Then in this case the item must be added to the Sprint Backlog or and additional item must be selected to be added.  Consider these important process improvements which arguably have no place on the Development Team's Sprint Backlog:

    • Involve customers in the Sprint Review
    • Create report XYZ to increase transparency
    • Product Owner will work more closely with customers to determine value for PBIs for more effective prioritization
    • Scrum Master will work with C-level to increase safety in raising organizational impediments
    • Development Team will collaborate during the Sprint Review on what to do next

    So many articles that frame process improvements as no less than primarily on the Development Team.  It's as if converting project mangers to Product Owners or people managers to Scrum Masters are lesser (frequency, severity, etc.) in nature than possible technical issues.  This despite the commonly cited reason that "agile implementations" most often fail due to organizations not adapting.  Technologists are often more accustomed to change as they must keep up with the ever evolving landscape.

    05:09 pm November 15, 2017

    Consider these important process improvements which arguably have no place on the Development Team's Sprint Backlog...

    That’s right. They would arguably have no place there. However, that does not imply they are unimportant.

    This despite the commonly cited reason that  “agile implementations” most often fail due to organizations not adapting

    Scrum often requires deep and pervasive change across an enterprise, and those changes are typically far more than Development Teams can accommodate even in aggregate. They face multiple dependencies and there is an organizational gravity to overcome. Scrum, however, is not a transformational framework and hence there is no prescription for effecting changes which lie beyond a team’s present competence, even if they are of critical importance. That’s where other frameworks such as Agility Path and Evidence Based Management may be expected to come in.

    Broadly speaking, the items you bullet-pointed are the sort of changes that might reasonably go on a transformation backlog.

    08:52 pm November 17, 2017

    Your "that does not imply they are unimportant" statement makes no sense: Who is saying they are unimportant?!?!?

    Each of my bullets is based on The Scrum Guide.

    11:17 pm November 17, 2017

    Not all of the improvements which are identified in a Sprint Retrospective necessarily translate into actions for the Development Team. As such, they might not be prioritized and planned on the Sprint Backlog. Since there is no explicit guidance for their handling, there is perhaps a risk of them being seen as comparatively unimportant.

    However, this is not the case. They are certainly important - it's just that they don't belong in a forecast of work for a Development Team, if that team will not in fact be actioning those improvements. Where else they go isn't something which Scrum would prescribe.

    05:01 pm December 31, 2018

    I am trying to understand what is meant by 'Scrum proved especially effective in iterative and incremental knowledge transfer.' Thanks for answering

    05:51 pm December 31, 2018

    In this statement  'Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.' what do they really mean by 'the point of work'? 

    07:23 pm December 31, 2018

    It means at the time and place where work is carried out. The implication is that Development Team members ought to be skilled inspectors. Timely inspection and adaptation reduces the potential for waste to accumulate.

    11:08 pm January 1, 2019

    Thank you Ian, for explaining and answering my question.