Continuing with this series is the updates to the Product Backlog including the introduction of the Product Goal in the 2020 Scrum Guide. After having just about a year to digest and practice Scrum with the changes to the 2020 Scrum Guide as it pertains to the Product Backlog and Product Goal, I would like to share my current thoughts.
Scrum Guide 2020
“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.
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.”
– Important distinction to call out here;
“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.”
It is not a wish list of all the possible things we might eventually want to put in the product. It is also not a dumping ground for “things we have to do, but just not right now, and I don’t want to forget about it.” These are wasteful things that teams do sometimes that make Product Backlogs insanely large.
“Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work. “
– Quite the word salad to unpack there. Refining Product Backlog Items can be achieved in multiple approaches. Some better than others in my experience. I like the Dual-Track development approach championed by Jeff Patton. Dual-Track lays out the approach of a core team within the Scrum Team, usually comprised of the Product Owner, UX, and Developer(Sr.), that meets with the customer/user to discuss what they need. Prior to meeting, this core team will have a high level discussion about what the customer/user is asking for and the problem it is solving. They will come up with a list of questions/risks/assumptions to bring to that meeting, and a plan to answer those questions/risks/assumptions. This core team then creates things like Story Maps, workflow diagrams, light-weight prototypes with the customer/user as a means of refinement. I like this approach because it is a very agile way of working and focuses on the product. I would advise looking up any talks with Jeff Patton where he discusses Dual-Track development. Or attending his Product Ownership course. Now I am not saying this is the only way to refine a Product Backlog. The team needs to figure out what works best for the team.
“The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.”
– This is interesting. Sizing Product Backlog items often leads to some of the tag alongs in Scrum like Story Points, Story Point Estimation and Velocity metrics. With sizing, my brain by default goes to Stories and slicing or narrowing stories down to something deliverable that provides some sense of value to our domain level user. Since we are talking about Scrum, Scrum doesn’t prescribe using stories at all. Everything is a Product Backlog Item. This opens up quite the debate about what a Product Backlog Item should be. Is a Product Backlog Item a requirements doc, is it a story, is it a bug, is it the building or modifying of an API or a Database Schema, is it the creation of a prototype, is it a SPIKE to investigate an open question or issue in or about the Product. Well to me, when using Scrum, the answer is yes. I have a mental issue with this since I feel that every Product Backlog Item should deliver value to our domain user. And to me, having a Product Backlog Item to create a requirements doc or to create a story, doesn’t actually provide any real value to our users.
Now I have another issue here. There are even some definitions out there that state, “The Product Backlog Item is anything that the Product Owner deems valuable.” Well that is a slippery slope now isn’t it. What if the Product Owner creates a Product Backlog Item to estimate the entire backlog with Story Points. That isn’t really providing any value to our users since all you get from that is a questionable estimate of when things will be done that is ultimately treated as a guarantee. But by this definition, it could be a Product Backlog Item. My little rant here is just to point out that while this is probably stated this way with the best intentions, it is often implemented with the worst outcomes.
Now the trade-offs part here is interesting in the Product Backlog. It is stating that the Product Owner has the vision of the Product in mind, and they can help narrow scope for the Developers. Remember, Developers are anyone on the Scrum Team that helps create the thing, from design to coding to testing. The issue is that seldom do very many Product Owners look to reduce scope. The art form of narrowing the deliverable down to capture what really needs to be accomplished by the user should be your guide. But with Scrum, I question how much the user is really thought of at times.
Scrum Guide 2020: Commitment & The Product Goal
“The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.”
– At first glance, my initial reaction was “huh?!” Sometimes I really think that Jeff and Ken are putting sentence structures together in a challenge to see who can come up with the most obscure way of writing something. But if we unpack this, it is saying there needs to be a goal the Product is striving to achieve. And the Product Backlog should be created with that Product Goal in mind. Makes sense right? Well caution here. I think it makes perfect sense, but I see just like how Scrum has been implemented across many organizations with disastrous results, this addition of the Product Goal in the Product Backlog can quickly go down this road.
I see SAFe style planning events with quarterly, semi-annual, and annual milestones being created. Gantt charts as far as the eye can see, and a very rigid approach to building software for the sake of sticking to the plan. I see these plans taking a dominant stance over learning and adjusting to what is really valuable.
So far, if you are going to use Product Goals, the best way I have found to avoid this is to keep the Product Goals small and focused. Do not create a Product Goal to “Increase Revenue by 25% by the end of 2024”. Although some people are arguing in the Scrum Community that this example is exactly what a Product Goal is. To me, using Product Goals for long term objectives can easily be twisted and lead to following your plan rather that adjusting as needed to the world around you, delivering early and often to drive the market you are in, and really providing value today to your user.
“A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.”
– Ok.
“The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.”
– This sounds an awful lot like a reminder to focus and work as a team on one thing at a time, not 20 things separately. But it also is saying to not switch objectives on a whim or flip flop between them. That all makes perfect sense. But again I caution, teams can easily fall into “this is the plan to reach that objective, and if we deviate from this plan, we will not reach the objective.” This thinking has caused many issues in the software development world. Delayed deployment of software, delivering a bloated product with more features than anyone wants or needs, refactoring of code to remove unwanted features (if you are lucky), and piling on new features that users really want without addressing the removal of the features they don’t like or use (usually what happens).
As always, feedback is welcomed.. I think I will move on to the Sprint Backlog and the Sprint Goal next…
Chris Pipito 