Watch the Video

Listen to the edited Audio

Summary

The initial draft of the 2020 Scrum Guide in early 2020 brought on lots of discussion in the community. 

Deferring the update for a few months gave more time to refine some of the key changes. One of which was the introduction of the Product Goal.

I welcome this introduction as I see it motivating more teams to adopt more longer-term planning horizons beyond the current Sprint. Several Sprint Goals deliver on the value promise of the Product Goal.

For teams who already practice product road-mapping, the Product Goal would represent the milestone that is currently being worked on.

Another bigger shift in the 2020 Scrum Guide was the removal of the structure of “Development Team” to focus on the overall team identity of Scrum Team.

From the perspective of team cohesion, I very much welcome the move. All Scrum Team members, including Scrum Master and Product Owner, are in this together, and equally so.

For beginning practitioners, this would ease the appreciation of a singular team identity. 

Thinking ahead, it does make the use of a powerful tool from professional team coaching more tricky. There we have a distinct separation between the team and the team coach. However, this would not present a true issue for many Scrum Teams, but is certainly something for me to keep in mind.

For more on this, please enjoy this episode using your medium of choice.

Quote Cards

Listen on Spotify (edited)

Full Transcript

– “Hello, hello, for all Scrum masters and Agile coaches out there, in the first instance, it is always useful to know how Scrum is evolving so that your teams that you get to support get the most out of the framework, and it just so happens that very recently, in November 2020, the latest version of the “Scrum Guide” went live. 

So in this video, we’re going to explore some of the major changes and see how they could affect your practice with your teams. Hello, and welcome to “Team Genius Live.” I’m your host, Georg Fasching, and this is an episode centered around the “Scrum Guide 2020” changes, in particular the introduction of a new goal in addition to the sprint goal. 

 

Now, we’re going to take a look at the “Scrum Guide,” which is the, sort of a central source of truth for how the Scrum framework develops over time, 

kept up to date by Ken Schwaber and Jeff Sutherland, and the way that they usually go about updates is that they use their experience and their engagement with the community out there, but they also share advance copies of these drafts with people that they know are working in the thick of it and training and coaching Scrum masters and teams out there. So whenever there are major changes, then these get rolled up and published into a new official version of the “Scrum Guide.” Before this release in November 2020, the last change was in 2017, and so in 2020, there are a few things that are worth taking a look at. One of them is the introduction of the product goal. 

So let’s take a look at what we’ve got here. Let’s actually have a look at the revisions first, maybe. In the revision history, just to get a brief overview of what we’ve got in there, is that overall, the “Scrum Guide” has been lightened up and made less prescriptive, so some things in there that, we might look at later are also related to the starter questions that you can ask in the Daily Scrum as a team as you’re checking in. Another one is that the team consolidation has been clarified a bit, which is quite good, and the product goal, as I mentioned, which is going to be the major focus of the episode today, and there is also some clarification around how the definition of done fits in alongside other aspects that are quite interesting, so we’re definitely going to look at that also, and then the overall text has actually been shortened, so it is clearer and easier to read and refer back to. 

 

So without further ado, let’s look at the product goal introduction. 

So the way that the product goal was introduced is that it is a commitment that corresponds to the product backlog. You might recall that the sprint goal is a commitment that corresponds to the sprint but is now very directly correlated or linked into the sprint backlog. So the product backlog has the product goal, and that is an overarching product goal that multiple sprint goals would contribute to. So the interesting thing here is that in my practice, I’ve found that not all teams, actually too many teams, I have to say, aren’t using any sort of product roadmapping, and the two that I tend to refer to to get started with is Janna Bastow’s Now/Next/Later product roadmap, and to get more value out of the planning approaches and something that’s more capable and more powerful as a communication tool, I would say, is Roman Pichler’s GO Product Roadmap template. I’ll make links to both of those things in the description below, and what I like about this update here in the “Scrum Guide 2020” is that even when you are using Scrum just on its own as a framework, you now have an encouragement to think on a higher level than just a current sprint, and that is really, really useful for product owners and, of course, also for teams to consider the wider context and to get a bit more appreciation of the purpose of what the current sprint goal is linking to. 

 

So you could think about the product goal as a product roadmap milestone. 

That is certainly a possibility in order to link it up that way. Another option is that you have something even bigger or that you have something which is beyond the definitions of the “Scrum Guide” but where you have a larger chunk of functionality that some people would describe as an epic that gets delivered over the course of multiple sprints, and that epic is your product goal. So the “Scrum Guide” is not prescriptive in exactly what you do with the product goal. It simply asks you to have one so that you are still practicing Scrum, and the product goal itself, as it says here, is a very, very short definition here, right. 

Product goal is the long-term objective for the Scrum team. Now, where we might need to be a bit more nuanced in how we understand this and how we practice this is this sentence here, “They must fulfil or abandon one objective before taking on the next.” Now, if we were to stick with this very strictly, that means that in a cross-functional team, as we would want to have in a Scrum team, the developers, the product developers, be that user experience, researchers, visual designers, software engineers, whatever you might require in the Scrum team in order to deliver the product, there’s always this ongoing intermingling, if you will, of discovery work for how best to do the feature. There is refinement work going on for upcoming product backlog items, and there’s the creation of the product backlog items firstly to get items ready for the sprint and then to deliver the items within the sprint. 

So if we then zoom out across multiple sprints and look at the product goal, if we were very strict with this interpretation here, it would mean that we complete all the work related to one product goal before we even start looking on the next one, but I think it would, of course, make sense to start doing some high-level breakdown of the product goal into lower-level product backlog items, refine them down and start testing some things so that you have the right information for the product owner as well as the team, not only to refine the items but also to order the items in the product backlog so that you have a flow. 

 

The other way to interpret this is to actually look at this as a natural flow of things and consider that a product goal, 

let’s say it was a milestone on your product roadmap and you’re introducing a new feature set in that, to finish the work on that one and then actually really start with another feature set with more of a blank slate, so I’ve seen that a few times where teams actually chose this route to go more distinctly from sort of a more delivery-orientated mindset over into a more discovery orientated mindset, and once they have just enough information to, in the first sprint, to go back and to deliver to do that there. 

The thing is, what we always want to ensure in Scrum is that at the end of the sprint that the team reaches a potentially shippable product increment, something that is of value, and once again, in the “Scrum Guide,” if we look at the definition here, it is defined now very specifically no longer as a potentially shippable product increment, which used to be the definition. Now, it says an increment is a “concrete stepping stone toward the Product Goal.” Now, what’s important here is this definition down here: “Work cannot be considered part of an Increment unless it meets the Definition of Done,” right, so the definition of done is a working agreement, of course, between, amongst the Scrum team, and it can change over time. 

So if you are going from a delivery sort of mindset or drive and finishing up with one product goal and then starting the work on the next product goal in order to be in keeping with the definition here: “They must fulfil or abandon one objective before taking on the next,” that would suggest once you’re done with that, you go back to your definition of done, change the level of fidelity to something lower than, you know, fully production-ready, tested, and so on and so forth, and whatever you had for full delivery mode, go back to what you are looking for to be in compliance with the definition of done for discovery mode, and say until we have enough validation of the problem space that we’re looking to cover in the next product goal and have done multi-prototype testing for different types of solutions, until we have done that, the definition of done goes to our discovery level definition of done, right. 

So this is how you would work very actively with your artifacts and definitions and still be in keeping with the definitions of the Scrum framework, and you would wanna keep an eye on your definition of done on an ongoing basis anyway to make sure it is always fit for purpose. So let’s go back one more time to the product backlog here. The commitment of the product goal is also set in the product backlog, as it says over here, and the product backlog itself then contains the product backlog items that describe what is being created in order to fulfil the product goal. Now, I mentioned this a couple of times, but just to be explicit, the sprint goal still exists, right, so if you look at the product backlog, we’ve got the product goal as the commitment. If we look at the sprint backlog, we’ve got the sprint goal as the commitment, and the sprint goal, I’ve done a number of videos that I’ll also link to in the description to help you create really good and meaningful sprint goals, and they still stand alongside the 2020 “Scrum Guide” version. So the sprint goal is one stepping stone that the team commits to in order to bring the product a significant step closer towards realizing the product goal, right. 

 

So that is there, and what we’re now moving on to is another change in the 2020 “Scrum Guide” update, 

which is quite good, is that there are these three major artifacts. We’ve got the product backlog, the sprint backlog, and the increment, and for each of them, we’ve got this commitment, right. For the product backlog, we had the product goal as the commitment. For the sprint backlog, we’ve got the sprint goal as a commitment, and for the increment, we have the definition of done as the commitment, right, so it’s now much clearer what the role of the definition of done is and how it relates. That has been cleared up very nicely in the 2020 version, and now we’ve essentially got three commitments that the Scrum team works along for every product backlog item that is being worked on that then, as a collection, creates the increment. 

They have the commitment for each of those items to meet the definition of done, and for the sprint backlog, the commitment is to deliver on the sprint goal, and just as before, not every item in the sprint backlog necessarily needs to be delivered, so that the sprint goal is being met, but the team and product owner must be really clear which items of the sprint backlog are actually required in order to meet the sprint goal, right, so once again, the team, the team and product owner need to be very clear on that, but the team can actually be successful in meeting the sprint goal without necessarily delivering all of the items in the sprint backlog. So through the Daily Scrum, the team continues to check in on their progress and how they’re doing, and in spite of having good refinement, if there are major discoveries, then the product owner and the developers work out what they want to do about it and what might need to change in the sprint backlog so that the sprint goal can still be met. 

 

So I think that’s probably good enough for an overview on the changes on the Scrum artifacts. 

The other thing that I wanted to cover while we are on this is the Scrum team. So up until the 2017 version, we had the Scrum team, which was product owner, Scrum master, and the development team, and we had the development team, which is the collection of the cross-functional team members, all the product developers that were in there, so there was always this duality of the development team and in the Scrum team as a whole, and some people liked that. Other people didn’t like it as much. I could see it either way. I didn’t have any strong opinion either way, I have to say, but now, this is all cleared up. There is no longer the development team, and the Scrum team, there is just the Scrum team. So you’ve got the product owner and the Scrum master and the developers, and once again, I always add this, the Scrum framework does not consider developers to be, software developers, right. 

We’re talking about a cross-functional team that includes all the team members that are required in order to create the increment of each sprint and include all the skills that are in there. Yes, they can be software developers and can be designers, user researchers, whatever might be required for the team to create the increment each sprint, and that is another nice clarification. So there was one more thing. In the Daily Scrum, you might recall that up until the 2017 version, there was in here a reference of three specific questions that should be asked of what people did since the last Daily Scrum, what are they planning to do until the next Daily Scrum, and any blockers that they might have, and the general understanding was that teams would be supported in really looking at this as what is it that every team member needs to do to support the team in meeting the sprint goal? What is it that they did in order for the team to meet the sprint goal? 

Ultimately, these questions were removed, and the purpose is now just made quite clear here that this is a daily planning meeting that helps the team to align, check in on their work, and it’s still limited to 15 minutes, still the purpose is for the developers of the Scrum team to come together and do this, and as long as it’s happening and it’s working well, then there is no need for other Scrum team members to be there. As before, my recommendation is always for the Scrum master and, in particular, even more so importantly, for the product owner to be available for any very, very quick clarifications, and anything that takes more than a yes or no, perhaps, right, that gets picked up right after the Daily Scrum, so the developers can really focus on the purpose of the Daily Scrum, finish that in under or up to 15 minutes, and any clarifications can be picked up with the product owner right after the Daily Scrum, so that’s the other thing here for the Scrum team, and I think those were the changes that I wanted to have in there, so if there are any queries about the 2020 changes and what they might mean, I can see we’ve got a few people joining live, if you’ve got any questions, feel free to put them in the live chat, and I’m happy to pick it up now. 

Otherwise, I’m just going to have a quick look while you may or may not be typing. Thank you very much for joining live, by the way, thank you. If you found these updates useful so far, feel free to give the video a like, thank you. There was one more thing that I wanted to mention. In the sprint planning event, so the reason I’ve done a number of videos now on the sprint goal is, again, not enough teams are really practicing the definition and use of the sprint goal as well as they could be, and in one or two of the videos, I’m even admitting to myself making a mistake in the early years of my practice, where I, for some reason or another, I completely misunderstood and misused the sprint goal, so it’s kind of a path of redemption for me to help others avoid the mistake that I made over the course of those few months where I did that. 

In the 2020 update of the “Scrum Guide,” there are now three topics in order to bring more emphasis. There used to be two topics, which is more the what and the how. What is it that the team is going to pull from the product backlog into the sprint backlog, the developers in the updated verbiage? And then topic two was at least a starting planning of how the developers are going to get started on delivering the top items of the sprint backlog. So now, there are three topics, which brings more emphasis on the why, the sprint goal, which was kind of an assumed given, but it was not just me, of course, who saw that the sprint goal was not observed and practiced well enough and widely enough, so now we’ve got three topics we’re starting with the why the sprint goal is important to review that as a Scrum team, and of course, this should not be the first time that this is being discussed. 

This is something that would have been covered in product backlog refinement previously, but just to reiterate and ensure that everyone is really clear on the value of the sprint and articulate that in a good sprint goal, so that is now topic number one. Then the pulling of items based on capacity of the team by the developers from the product backlog, top of the product backlog, to refine items into the sprint backlog, that is now topic number two, and then the identification of how the work will be delivered at the starting point, at least for the first few items so the team can get off to a great start, the developers can get off to a great start in the new sprint, is now topic number three, so that’s another big change, I would say, that is very welcomed by me. I think that should help people to keep the sprint goal really top of mind and really appreciate the importance of it.

 

Too many times, I’ve seen teams not use the sprint goal, and then it was often an uncomfortable situation because they just used the items in the sprint backlog, and they didn’t deliver all the items. 

Then they were not considered to having had a successful sprint, but with the sprint goal, we have seen something bigger, something more important, something that can be delivered even if only the majority of the key items that are really required, most of the items are in there, and really holds the purpose of the whole sprint. So that is an overview of the changes in the 2020 release of the “Scrum Guide.” I’ll put a link of this in the description below so you can also review what is going on there. Once again, Scrum is a lightweight framework that helps you as a team to solve complex challenges, particularly for service development, and there’s now also a wonderful definition in here that helps you to create a product. 

Product is a vehicle to deliver value, and you can always add other practices within the Scrum framework, but just like with a scaffolding, if you remove some of the key parts of it, the scaffolding loses integrity, and in Scrum, if you omit some of the practices or parts of it, then it’s no longer Scrum, and your mileage may vary on what happens, and there’s no judgment whether you do or do not. My only encouragement is for you to be aware of the impact of what you’re doing and keep testing it and ensuring that as a team, you always get the most value of how you’re doing the work and going about it in service of your customers. 

All right, so that about wraps it up. Thank you so much. I hope this was useful. Feel free to acknowledge any value you got out of this with a Like, please, and once again, I would like to share the announcement, the launch roadmap for the monthly learning club is now clear. It’s going to go live in January with the first live training session. Signups will start from December, where I’m also going to release some bonus items into the membership area, so this will be a budget-friendly and time-friendly high-value learning, interactive two hours every four weeks, including practice time and Q&A time. If you were to join this as a member, you can also suggest topics for these training sessions, and you can vote on topics as well, so I’m always getting steer from the members to ensure that the highest-value training topic is being covered next. 

So that’s it for me. My name is Georg. This is “Team Genius Live,” episode 12, focused around the 2020 “Scrum Guide’s” changes with an emphasis on the product goal introduction. 

All the best from me, and have fun in the practice with your teams, and until next time, thank you.”

 

==end of transcript==