What are the new changes in the Scrum Guide from 2020? The current content is now 13 instead of 19 pages. Are the changes significant for the whole Agile society?
Be sure to read the Conclusion sections below.
Scrum has changed in 25 years. Is this change good? When I heard the news, I immediately researched the new in the Scrum Guide. I admit I was quite surprised. What has changed was quite different from my expectations.
The first thing that impressed me was the even shorter version. The Scrum Guide is now 13 pages long. So far it has been 19. I have always shared my opinion that this guide is quite short for most people. Beginners do not have a great chance to learn detailed and useful material for their work.
What are the changes in the Scrum Guide from 2020?
The first change is the use of simpler language.
The creators removed the context of software development. So they want to make their framework even more comprehensive.
Other innovations are slight changes in text format such as re-organized content (e.g., "Measuring Progress toward Goals").
There is already a so-called Product Goal, for which your Product Owner is responsible.
No more talking about roles. For example, the Product Owner role is now just a Product Owner.
The Development Team is now just Developers.
The increment was "potentially releasable". It is now "In order to provide value, the Increment must be usable".
The term self-organization is now self-management.
Sprint Goal is now an official part of the Sprint Backlog. So far, this has only been a good practice, but not part of the manual.
Definition of Done is now much clearer throughout the Increment.
There are no more 3 questions during the Daily Scrum event. What you will talk about during this meeting is entirely your choice. As long as you inspect the progress.
During Sprint Planning, an important official topic was "Why Sprint is Valuable to Stakeholders".
The Sprint Review (known as the demo) is already in the context of a review from both the Sprint Goal and Product Goal perspectives.
The Servant Leadership term no longer exists. The current term is simply Leadership.
Scrum Master and Product Owner can easily participate in the Daily Meeting event as Developers.
The Scrum Master already assists the Product Owner in finding techniques and defining a Product Goal.
What is the Product Goal?
As this is an entirely new topic and at the same time unclear again, let us discuss it in more detail.
This part of the article is based on the publication of Dave West, who only shares some details at the moment. I have taken out only the most important topics and I have not quoted abstract and vague parts of his article.
As these explanations may not be enough for me, or they may push some Scrum teams in an unproductive direction, I will post additions to all of the points here. In these additions, I present my point of view and recommendations for the teams. I also share examples for additional clarity on each point.
Product Goal is the topic that addresses the question of "why" we do all this work.
The word Goal is intentional because it describes two things:
This is something to strive for.
It is measurable when you have achieved it.
The new Scrum Guide does not give details about the details of the Product Goal, thus allowing Scrum teams to form the goal in the right way for their context. For example, some Scrum teams may work for a quarterly Product Goal with clear specifics. Another Scrum team may have a Product Goal that is more abstract.
Here are some of the features of Product Goal:
It is recommended that the Product Goal be clear and concise.
My addition:
Product Goal must be understandable to all. This includes the entire Scrum Team and stakeholders with access to team artifacts.
Example: Your director opens your online resources (such as Jira or Confluence) and reads the purpose of your product. Unfortunately, he doesn't understand anything.
The goal of the product can be achieved without completing all Product Backlog Items.
Addition:
The Product Owner role, as responsible for the Product Backlog and for the product as a whole, may decide to re-prioritize (drop) the unfinished Product Backlog Items. That is, choose not to do at all in the near future. This choice and change in prioritization must be fully compliant with the product requirements.
Example: Your Product Owner can remove User Story regarding importing data from a .pdf file, as it considers importing data only from a .xlsx file into just enough for your product. Make sure no investor or director gets mad because this Item is below in your Product Backlog.
The Product Goal may change over time. Original idea: "understanding of the Product Goal will be refined".
Addition:
It would probably be a good practice to refine your Product Goal rarely only when strong needs are identified, or at the end of your chosen period to achieve the goal.
Example: As you already know, the Scrum community does not accept the radical change of Sprint Backlog Items during the sprint. In this way, we achieve calm work without nerves and crises. When necessary, modifications and changes are made in the next sprint. Changing the Product Goal would also have a negative effect on performance.
Product Goal is transparent in the Product Backlog in the same way that Sprint Goal is transparent in the Sprint Backlog. Each Scrum team will do what is necessary to make this happen depending on their environment.
Addition: In fact, everything should be clear here. The purpose of the sprint is no secret and everyone has access to it. Each Scrum team can publish it in their work software, or print it out and hang it on the wall in their room.
Product Goal compared to Value Proposition
Here's another easy explanation for Product Managers, which is not from Dave West's article, but I think it would be quite useful.
In the PMA Product Management course, we learn what Value Proposition is and the students have an exercise in which they define it.
Product managers need to know what Value Proposition is.
Also, in this context, we can add that the Product Goal can be adopted as a short version of the Value Proposition, which concerns a specific period of time. However, instead of a specific period of time, you can think about your product goal for a specific version of your product, if that will make it easier for you.
And since the Scrum Master role helps your Product Owner find techniques for defining a Product Goal, if you are a Scrum Master or a future one, research the Value Proposition topic right away, as it may be helpful.
Conclusion
The Scrum Guide is now even shorter, instead of becoming more detailed and offering more knowledge. Instead of more free knowledge for everyone, this reduction is likely to keep the need for additional detailed courses. Simplifying the language should help readers. There is some improvement here, but the whole abstraction and still many vague terms remain.
"Increment must be usable". Usable is again an abstract concept.
I would recommend everyone to read the term Usability in product development.
Also, note the relationship between "usable" and the absence of serious defects. That is - your work has no bugs.
The Scrum Guide now really looks like a brochure or an advertisement. But there is no longer version. Everyone in the world interprets this guide as they wish. Everything remains the same as before.
Definition of Done has already been explained, which is pretty good.
Since Scrum Master and Product Owner are also developers attending the Daily Scrum event, you need to be warier of conflicts of interest. Also without the old interesting questions, and since everyone is a developer, the event is more and more like people who come together and talk. Specialists who do not know those old classic eternal questions will not have an example of how to inspect and discuss their risks and problems.
Scrum preaches events of fixed duration. However, this does not prevent team members from meeting as many times a day as they wish and discussing their problems, regardless of their duration. The Daily Scrum event seems a bit redundant now.
The competent Product Owner seems to need to know more and more product practices in order to be able to cope with the product goal. At the same time, however, your Scrum Master should support his colleague Product Owner in this part as well. There is still the idea that the Scrum Master role should have the best "research skills" and competencies to support the very important Product Owner, who should be responsible for the product and should not be a beginner amateur.
Contradictions remain with the new changes.
Maybe we will meet a new generation of Scrum Masters, for whom Leadership is different from Servant leadership and probably have not heard the old term.
The Development Team at least gave a sense of unity among the developers. They are no longer a team, only developers.
Advanced teams really have more leeway and can use their own definitions, interpretations, and practices. In fact, advanced teams have always followed their own practices, work styles, and rules (which actually often break Scrum rules).
All modules and topics in the Scrum course of PMA for example will keep their old content so that everyone can learn the old rules. The new will be noted in the relevant comparison sections. Let every professional have a basis for comparison with before and now and let everyone choose a team to choose their terminology, rules, and ideas.
- Previous article The five functions of Fayol's management
Related posts:
- What is the Product Life Cycle and what are its phases and cycles. Strategies for the stages of the product life cycle
Definition of the product life cycle and which are the phases and periods of the product life cycle. Strategies for dealing with marketing problems in different phases.
- What is a business plan? Complete instructions on how to write one
What is a business plan: definition and instructions on how to write an extended business plan and product strategy. The business plan is a guideline document to help a company manage its expectation and issues related to product strategy and development.
- Market research. Definition and classification of market research
Market research. Definition and classification of market research. Problems and subjects of research.
- Career planning and development: Definition and goals of career development
Career planning and development: Definition and goals of career development. A career is a set of positions that a person has held in his professional life. Career planning is a process in which personal skills, qualities, knowledge, motivation, and other characteristics are realized, information about job opportunities and choices is collected
- What is the internal recruitment? Internal recruitment as part of the career planning process
Internal recruitment is the decision to relocate current employees to vacancies in the organization. These staff actions include promotion, transfer, or relocation, but at the same hierarchical level up and downgrading of employees to a higher or lower hierarchical level.
- Organizational change management in successful companies
Organizational change management in successful companies depends on many factors like employee engagement, motivation and the application of strategies in the process of change
- Different types of managers
Good management is a matter of well-chosen managers. They are the intermediaries between all employees in the company or organization
- Top 6 Project Management Trends for 2022
What will happen to project management in 2022? The article describes the professional opinion of Anton Radev, Managing Director of Project Management Academy Ltd (PMA)
- What is marketing and types of social groups’ research
The report explains what marketing is and examines the study of social groups as a management strategy for product production.
- The differences between Project Manager and Product Manager
The article describes the informal differences between the project manager and the product manager and gives examples and explains many situations, responsibilities, and obligations of the two positions.
