What do you think about the revision changes of Scrum Guide 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?

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.

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"

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?

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

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.

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.

@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?

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

Thanks,

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.

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

Why would these not be included in the revisions page?

Why indeed :-)

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?

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

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

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.

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?

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.

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?

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

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.

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.

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.

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.

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

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'? 

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.

Thank you Ian, for explaining and answering my question.