Changes for the next update of the Scrum Guide

Thank you for submitting this. Here are my opinions and feedback.

Proposition 1

I believe you are under the false assumption scrum itself is open to inspect and adapt on the required elements beyond the team trying different approaches that meet 4the requirements or realizing scrum is not a valid tool for the teams use case.

The proposal completely undermine the concept structured as a framework. It would also give license to do anything falsely under the name of scrum as an experiment.

The guide stresses, “Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value.”

Proposition 2 

Discussing the Product Backlog, “The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.”

Looking at the Product Owner accountability:

“The Product Owner is also accountable for effective Product Backlog management, which includes:

• Developing and explicitly communicating the Product Goal;

• Creating and clearly communicating Product Backlog items;

• Ordering Product Backlog items; and,

• Ensuring that the Product Backlog is transparent, visible and understood.”

Leaving the Product Backlog open so anyone can add leads to a few questions:

1. Is there an issue working with the Product Owner in order to have items added to the Product Backlog? E.g. PO availability (Let’s not mask this problem)

2. Is the PO saying no? If so, the change would completely invalidate the PO’s ability to perform their accountabilities.

3. Is it easier to submit work? Easier for whom? How does the team get engagement to seek clarification?

4. Are stakeholders forbidden from submitting to another input mechanism so the PBL can be kept isolated and structured. The PO can work moving over items deemed to be possible future work?

5. Is the PO expected to review to dedupe vs a conversation where they can point out if work is accounted for? If any one can submit, does this scale?

6. Even with the above concerns, the PO can technically already allow your suggestion with existing wording without encouraging the practice from the SG line, “The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.”

The last important callout here is your point about transparency. Transparency of what specifically? The PBL is effectively an agile replacement of a roadmap where the details are “more” of a living “document”. The description is specifically for what is “needed” to improve the product. If anything can be added at any time, the suggested “need” has not been validated (or validation is unknown) through the product team. The PBL as an information radiator with these items can lead to misaligned expectations and confusion over the product. It can start conversations of people agreeing and disagreeing while arguing over priority, all before a team has a chance to say, that already exists, that is not suppose to exists, or that is not work that will be picked up. (Maximize the work not done)

Proposition 3

This proposal appears to want to redefine scrum itself. The suggestion to change the theory itself is odd. Suspending disbelief, it still point out the disconnect of scrum intentionally being a framework which is an abstraction, while the suggestion is to move away from abstract with the theory of the abstraction… maybe I’m missing something?

Proposition 4

This appears to be adding arbitrary qualifiers and brings in discussing metrics. First, the qualifiers, adding “monetary or other” accomplishes?

Describing the clarity around the value of the product is an odd value to claim it adds and indicates a separate large disfunction.

“The metrics of this value are established jointly by the Scrum team, the Organization and the end users of the product.”

This quote is part of the second issue. Prescribing metrics and approaches to metrics. The creators went to great lengths to avoid this by design. They even removed burn downs (beyond referencing them to say they are outside of scrum tools).

It also calls out an issue that shows a lack of understanding of emergent work.

If the metrics relate to the product, all you can do is measure and adjust with emergent design, work, requirements. The closest to what you mention is the sprint backlog of an agreed upon goal to try and drive delivery to the best of the teams ability. Even the outcome isn’t known until after the customers start using it, and the customers commonly don’t know what they like in concrete implementation until the see it. In agile, this would be contract negotiation you seem to be seeking. Stake holders are different, but a lot of similar concepts apply.

if metrics are about team performance evaluation, you are no longer talking about scrum if the team brings stakeholders and users into that. Typically individual and team performance evaluation is also part of a people manager’s role outside the scrum team. The team might want these to evaluate themself, but that is not stakeholders and users being brought in.

If it is strictly about the team understanding the work, I’m confused by Sprint Planning, Retrospectives, and “Backlog Refinement” (if occurring) doesn’t address this specific concern? I’m also curious why issues relating to this problem don’t manifest in the sprint Review.

Proposition 5

I like trying to see clarity on organizations label. The issue is, outside the team, these labels are intended to be abstract general encompassing terms for a common concept.

The definition provides seems to only attempt to define an organization from the perspective of the scrum team, which limits providing value in any other context, and I question if it provides value in the context of the team. It also is still ambiguous enough to have no clear placement, size, or purpose with the definition beyond funding.

Proposition 6

This is interesting for a couple reasons. 1. The guide doesn’t talk about how to use metrics. The section you mention adding a statement is about the guide not discussing or placing requirement with these approaches and tools, yet you want a prescription that alludes to metrics needing to be used and explicitly how they cannot be used.

If it is not implying metrics need to be used, then you are recommending adding a prescription for a tool not part of the framework?

The other interesting pieces are:

2. If following Proposition 1 you suggest, can’t it just be an experiment to use these metrics against what your new statement says and call it an experiment?

3. Is this an attempt to force prescriptions outside the team? Eg. Managers can’t use forecasts against the team? If so, I get the drive, but now you want to prescribe something outside the group that selected the prescriptions to address an issue that is outside of scrum itself with a people manager. The Scrum Guide seems like the wrong place for this issue. Most of the scrum guide talks about external requirements for the team, eg they need to be able/allowed to be self managing, but it doesn’t make prescriptions outside the team as they are not really enforceable. This is also why the SM is useful. They teach scrum aspects, play interference as needed, and can “persuade”.

If you think people using scrum respond well to “the scrum guide says…” (which I support), try telling a manager or director “the scrum guide says…” relating to how they evaluate their people, especially if they allowed the team self management of delivery just to have the team select something that now goes beyond that scope into people management.

Even if my reading is off on your suggestions, I counter, wouldn’t that be an issue for some others if the proposals were adopted?

Thanks for your comments

Short feedback to

"I believe you are under the false assumption scrum itself is open to inspect and adapt on the required elements beyond the team "

No; I am perfectly aware  that Scrum, in its current state, does not allow itself to be open for inspection and adaptation.

I suggest (please pay attention on "suggest") that it should.

That's a purpose of "First amendment" if we should call it that way.

About other comments

Proposition 2: Please pay attention to the part of the proposition where I write that the Product owner should keep the exclusive right to DELETE everything and anything what he considers unnecessary from the Product backlog. So this proposition removes only a very small portion of his authority

Information of any kind is an asset. That's why the circle of having Product Back open for new incoming information, and deciding to keep or delete it, is better compared to having an arbitrary barrier for incoming information. Transparency, inspection and adaptation. 

 Proposition 3. If you would follow the link at the proposition you can read a concept where I suggest seeing information as a matter moving within time and space, not as an abstract, at least in a framework of Information tech. I don't insist that people should accept this concept, but its worth publishing and discussing

Proposition 4 . Could be the phrase you quoted, "The metrics of this value are established jointly by the Scrum team, the Organization and the end users of the product"  should be rephrased differently.

What I meant was that if metrics are monetary, i.e. then there is trade: exchange of product or its increment for money, the deal automatically establishes  the agreement between Scrum team, organization and the end user who buys the product(or should I write customer).

But when the metrics of value are NOT monetary and this often happens, then all parties involved with a product: scrum team, organization, customers and end users should have an agreement about joint standard of metrics.

I can confirm that in practice absence of such standards often creates a barrier between scrum team, organization, customers and end users

Proposition 5. Some clarity and defintion of "organization" would not hurt the Scrum guide.

If anyone will propose better definition, I will be only glad.

Proposition 6. Weaponisation of velocity, and particularly the "story points" are slowly becoming a cancer of Scrum, often preventing whole teams form performing normally.

The sooner this issue will be addressed, the better, and just as with Proposition 5, if anyone can suggest better words then I did, I will only welcome it.

Once again thanks for your reaction.

If you are going to be rude about your opinion you inflict on everyone here. Please stop or go somewhere else.

you have no right to post asking for feedback and even solicit disagreement, then get rude when what you request occurs.

Joshua Wiechman I honestly don't know what part of my response you have considered rude, but my excuses anyway. I appreciate feedback and discussion, and especially appreciate critical opinions.

Ok everyone, really, there are great Scrum practitioners here. No one has any objection, support or own ideas? Scrum guide can be updated any time, soon, and does not anyone has anyone to say about what will be "it's in the Scrum guide" from next update on?

Its all like old "take care of politics or politics will take care of you" concept...

Think whole idea of framework is to draw boundaries (frame) on which you can do "freedom". But freedom stops at a frame. 

That does not say that you cannot use scrum to be inspired to experiment and make your own frames, but that is no longer scrum however scrum-like it may look.

It also does not mean that the scrum-like framework you derive from it is in any way inferior, it can prove to be better, especially for a given organization.

In my belief in general there would be ideally three states you can find organization to be in relation to scrum. N

1. Total chaos - you randomly implement parts of frameworks not quite understanding what are doing hoping it will somehow make you agile.

2. Generalized Order - you implement scrum or some other framework by the book 1:1 and change organization to fit it.

3. Tailored Order - you deviate from the framework intentionally to have it better fit your organization.

Seems to me it its quite easy to think you are 3. while you are in fact 1. 

Think to deviate from the book you should likely understand it first to know what you have changed and how that will affect things.

Its like creating new cook recipe in a way, just can remove some the salt and add some MSG instead to cut on sodium, but you cannot just remove the salt without knowing what salt did.

Based on what I just mentioned means that scrum is not the most ideal framework for most organizations but believe that most are stuck somewhere around 1. thinking they are gourmet chefs of agile doing 3. while just following the scrum would at least provide give decent meal ;)

But in general I think scrum guide should not promote anything that could make organization get stuck in 1. validating it with some line from a guide.

The Organization (firm or institution) doesn't care about Scrum guide in most cases. Scrum team is expected to act as bosses say, and they pay the bill, so money talks.

Its Scrum team who is usually turning within trying to fit both into organizations whishes and instructions, and fitness to Scrum guide.

The Scrum Guide provides guidance on a framework.  A framework is a support structure.  I like to explain it to people using the analogy of a house.  A house has a blueprint that creates a framework.  It provides guidance on where to place walls to support the weight of the structure. It provides guidance on where to place electrical outlets to adhere to local building codes. It provides guidance on where to place plumbing to protect it and provide access.  It may also suggest that a boundary of walls will be a bedroom, bathroom or closet.  However, that is a suggestion and not a hard set rule.  We all know of people that use rooms for different purposes such as a "bedroom" is an office or fitness room.  I know of instances where a building that had a blueprint designed as a single family dwelling became an office for a small business or a day care facility.  

In my opinion, by being somewhat vague the Scrum Guide provides enough guidance to form a basis for something that can be a success.  But it is not so prescriptive that it hinders it's use.  Your original suggestions were not bad but I would not want to see them in the Scrum Guide.  They are great for use when helping some group of individuals to better understand that the Guide is not prescriptive and you can use your own creative to adapt your activities/processes to something unique to your needs. 

There are a lot of conditions that impact a group of individuals from converging on specific procedures, standards, and practices.  All of them shape the implementation of the Scrum framework and "Scrum Practitioners" need to be able to evaluate those conditions to help people better adopt the framework. 

Personally, I have not encountered many groups of individuals that utilize the Scrum framework the same. But the same can be said for software development frameworks like Ruby on Rails, Django, React, Angular, etc.  Every group of individuals will implement them in the best way to solve the problems that they are facing. 

Side note: I want you to notice that I did not use the word organization in my response. 

Thanks for your input Daniel.

One important thing is that all six suggestions are separate from one another, so if you reject one or are skeptical about it, another one should be considered disregard.

Unsurprisingly the idea of making Scrums impunity less rigid and rules less mandatory caused most discussion.

But other points  are equally important.

Let me first mention an aspect which you deliberately don't mention: the organization.

As I wrote above "organization" is mentioned in a Scrum Guide 11 times. The 2020 version is bringing organization directly into creating Definition of Done.

This is happening without ever mentioning what should be the relationships between organization and scrum team, which are taken for granted.

In practice there is plenty of evidence of "organization" (firm or institution) not only refusing to support Scrum which they claim to have adopted, but literally ordering antipatterns: like dictating what should be said at sprint revue, prohibiting retrospectives, appointing five product owner's to one product, and so on... Many organizations threatening to cut budget or fire people if antipattern which they order will not be followed.

Absence of any mention of what should be the role of Organization in Scrum, and what should be its relationship with a Scrum team is greatly contributing to this situation. Especially considering that in a same time Scrum Guide is very demanding about following the rules, when it comes to the Scrum team itself.

Just wanted to update everyone that creators of Scrum have opened the Scrum guide for suggestions about upcoming updates. If you would go to the "Scrum guide" section of this site, there is currently the option(contact link) for everyone to send  their  own suggestions.

I beleive its a smart idea to discuss each idea at this community first...