In 2020 Jeff and Ken released the new Scrum Guide. What changes appeared after another three years of observing teams working in Scrum? And how those changes affect business analysts?
The Scrum Guide is the description of a framework for teams developing a product. It presents events, artifacts, and resposibilities in a team (Scrum Team, Product Owner, Scrum Master). Scrum gained huge popularity in IT. Many business analysts are working in Scrum teams or cooperate with those.
The Product Goal
The change I love the most about the new Scrum Guide is the introduction of a Product Goal. I couldn’t imagine a change more valuable for business analysts than this. We as business analysts focus on delivering value to stakeholders. Driving teams’ attention to this value was the most challenging aspect of our work. Of course, working on user story details and other stuff was challenging too. But at the end of the day what makes the product increment valuable was orientation in the right direction.
Many times it was very difficult for business analysts, UX designers, and other specializations who care about business value. In many cases, scrum teams claimed that this is just the product owner’s concern. They didn’t want to waste their time discussing goals wider than a sprint goal.
This is why I’m amazed by the changes to the Scrum Guide 2020. The authors drive attention to the fact, that Scrum is not only used to work effectively in a team, but to produce more valuable business outcomes that customers truly need and are satisfied with. Actually, that was the primary goal of moving away from the waterfall approach – to avoid developing solutions, which appear useless for customers.
What the introduction of product goals means to business analysts? That they would no longer be seen as office weirdos who force others to think about some boring goals. The whole team should be committed to the product goal. They should take part in its definition, and validation if the direction of product development is truly to be valuable for the customer.
Teams’ attention should be focused on striving for goals wider than sprint goals. Creating product goals means adopting the use of product roadmaps, product visions, and product strategy on the market.
I think that by adding the product goal to the Scrum Guide the authors showed that they really understand and care for business outcomes which are (or indeed should be) the purpose of each team’s work.
The Scrum Team
Another change to the Scrum Guide 2020 is the resignation of the distinction between Development Teams and Scrum Teams. How the authors commented on the change was that they would like to avoid separation between a product owner from the rest of the team. It used to happen that a product owner was said to be the only one who should be concerned about the customer requirements and all of the other boring stuff, which implied that developers could focus on development only.
I’ve heard many times that the goals and likewise are the concern of the product owner and team members are only there to deliver what the product owner would like to have. It made life more difficult for all of those who strive to introduce to companies a culture of customer-centricity or involving all employees in the active co-creation of goals. It is believed that this would increase engagement but also the value that the company can gain from listening to these smart people working on the product details.
So again, the authors noticed a misunderstanding or misuse of Scrum and tried to prevent it. I love this change too because it encourages the whole team to care about the value delivered by the product to the same extent as a product owner does. All team members should think about it, co-create it, and be engaged in its evaluation regarding its direction.
The Developer
A member of the scrum team is called a developer. There were a lot of discussions around business analysts working in Scrum. Some people claimed that there is no place for business analysts anymore because the role is not mentioned in the Scrum Guide. By the way, the testers, project managers, CEOs, and other important roles were not mentioned either.
The authors seeing this misunderstanding wanted to straighten this out. “The developer” tag it’s not to exclude anyone from Scrum but it’s just to simplify. It means that business analysts as well as other roles are welcomed to take part in the development conducted in Scrum.
13 pages
The content of the Scrum Guide 2020 was reduced from 17 to 13 pages. It’s one of the shortest documents I’ve ever seen which is that famous all over the world. It shows how much simplicity is important nowadays and how short content makes it easier for the recipients to digest it. Maybe we as business analysts could learn a lesson out of it too.
Better times for business analysts
I truly think that the changes in the Scrum Guide 2020 bring a lot of valuable shifts in the mindsets of scrum practitioners which drives the attention of teams to business value, effective cooperation between teams by not excluding anyone and not leaving the value responsibility to product owners only.
Read the 2020 Scrum Guide: https://www.scrumguides.org
