Getting Started with Product Delivery

Product Backlog & Product Goal
(Part 4 of 10)

When the “Why” is clear, the “How” is easy.

Vincent Carter
Straight Scrum

--

There are a lot of books and articles about the subject of a Product Backlog. So what hasn’t been written or discussed a million times already about Product Backlogs? I would like to expand on the 3 elements of the Product Backlog that I mentioned in the previous installment.

In the previous installment, “Product Roadmap”, I stated that instead of including just the 2 elements that the Scrum Guide uses to describe the Product Backlog, the “why” (the Product Goal) and the “what” (the items in the Product Backlog that fulfill the Product Goal), the Product Backlog would be better served by containing 3 elements with the addition of the “how” (The Product Roadmap). So let’s explore these 3 elements.

Element #1: WHY (Product Goal)

Element #1: WHY (Product Goal)

Using the title of a book from Simon Sinek, we’re going to “Start with Why”. The “why” for our Product Backlog is the Product Goal. Per the latest 2020 Scrum Guide, there are three artifacts within Scrum that received a new attribute called a “commitment” which is designed to enhance transparency and focus. One of the three artifacts is the Product Backlog, and its commitment is the Product Goal. The Product Goal describes ‘why’ we are doing all of this work. It describes a long-term objective or future state of the product and serves as a target against which the Scrum Team plans. Using the Product Vision as the overarching goal, the Product Owner should work with their Stakeholders and Scrum Team to brainstorm as many Product Goals as possible. Don’t worry about the order of the ideas or how crazy an idea may be. The important part at this stage is to not reject any ideas but instead foster the creation of as many as possible. You are going to create several Product Goals; however in order to provide focus, there can only be one active Product Goal at a time, and before the Scrum Team can take on another Product Goal, they must fulfill or abandon the current Product Goal.

Monty Python and the Holy Active Product Goal: Then shalt thou count to one active Product Goal, no more, no less. One shall be the number of active Product Goals thou shalt count, and the number of the counting shall be one. Two active Product Goals shalt thou not count, neither count thou zero, excepting that thou then proceed to one…

Example of Hypothetical Product Goals using the company SpaceX:
We can come up with a hypothetical Product Vision of “To populate Mars”. It’s succinct and easy to imagine but also a bit audacious. Some of the Product Goals that could help us get closer to our Product Vision of populating Mars include (remember, these are long-term objectives):

  • Build housing on Mars
  • Get to the moon
  • Go to Mars
  • Build a rocket able to orbit Earth
  • Avoid deadly cosmic radiation
  • “Earth to Earth” space travel
  • Deliver a satellite to orbit
  • Build bigger rockets
  • Floating spaceflight operations platforms
  • Figure out long-term habitation on a space station
  • Grow Potatoes on Mars
Element #2: HOW (Product Roadmap)

Element #2: HOW (Product Roadmap)

In the previous installment, I talked about the importance and value of having a Product Roadmap. The Product Roadmap is the ‘how’ for your Product Backlog. Continuing with our SpaceX example, we would now look to do some affinity mapping, removing, and ordering of our Product Goals. There are a variety of ordering methods such as Stack Ranking, Kano Model, MoSCoW Method, or Cost of Delay that you can use to help with ordering your Product Goals.

Example of an Ordered List of Hypothetical Product Goals and a Product Roadmap using the company SpaceX:

  1. Build a rocket able to orbit Earth
  2. Deliver a satellite to orbit
  3. Build bigger rockets
  4. Floating spaceflight operations platforms
  5. Figure out long-term habitation on a space station
  6. Get to the moon
  7. Get to Mars
  8. Build housing on Mars

Once you have a nice ordered list of Product Goals, use a Product Roadmap template to plan out your first four Product Goals. This will become your high-level visual summary that maps out how the product is likely to grow across your major releases.

Sample Go Product Roadmap+
Element #3: WHAT (Product Items)

Element #3: WHAT (Product Items)

Now that you have your Product Roadmap, it’s time to activate your first Product Goal and add it to your Product Backlog. You can do this however you see fit. The Scrum Guide does not state how, only that the Product Goal is in the Product Backlog. The next step is how you can use the single active Product Goal to help with keeping a healthy and manageable Product Backlog. Create and add only the Product Backlog Items/Features (PBI) to your Product Backlog that help you with meeting your active Product Goal. Once you’ve done that, you would continue to refine this list by breaking down these Items into smaller and more manageable items that can fit within a single sprint as well as ordering them with the most important items appearing at the top of the backlog.

Note: Your Product Backlog will and should contain more items than just the items that align to your active Product Goal. These items could include but are not limited to things such as Enhancements or Changes, Fixes or Defects, and Technical Debt

Conclusion

The Product Backlog makes potential value transparent and is the backbone of your Product. Make sure that it is always up-to-date and well maintained. And make sure that you remove the items that have started to age or no longer make sense to add to your Product.

INSTALLMENTS

I am very interested to learn what you think about this topic. My LinkedIn profile is https://www.linkedin.com/in/phooey

GO MAKE A HULLABALOO!!!

--

--

Vincent Carter
Straight Scrum

Enterprise Agile Leader (aka An Incrementalist). I write about agile & organizational change. https://www.linkedin.com/in/scrum-tious/