This article by Martin Hinshelwood entitled—If your backlog is not refined, then you are doing it wrong; inspired me to write this article.
Here’s the LinkedIn post with some valuable commentary…
I wrote the first edition of my Scrum Product Ownership book in 2009, then a second edition in 2013, and a final / third edition in 2019. There was a period of time from ~2007 to 2020, where I was spending a majority of my time teaching and coaching in the agile product space.
One of the top three topics I explored over the time was Backlog Refinement. I would often coach team refinement sessions as a means of exploring, explaining, and show good practices for emerging and maintaining a solid backlog.
Often other product owners would attend to observe it as a fishbowl learning experience. While I’ve found no process or recipe for effective refinement, there are a set of patterns that have proven to be useful.
The chicken or the egg
It’s a bit of a chicken and egg problem. Which comes first when transitioning to agile ways of working? Do you re-organize or restructure your organization first – setting teams and roles up for more agile execution? Or do you align your product, application, and workflows into value streams to feed to your teams? What a conundrum.
Ten years ago, I saw most organizations leaning into organizational changes and not putting much thought into the value streams their teams would be working on.
Now it’s flipped a bit, and there’s a strong focus on value streams, probably influenced by SAFe, amongst many factors. And then, the executing organization is composed as an afterthought.
I wrote the first edition of my Scrum Product Ownership book in 2009. Looking back, twelve years seems like an eternity in the agile universe. Perhaps it is. Since then, I’ve published two more editions, with the last hitting the streets in 2019. At this point, I don’t envision there being a 4th edition, but you never know.
Around 2012, I developed a Product Ownership maturity and assessment tool to accompany the book’s themes and ideas. It was a simple spreadsheet with ~20 areas of consideration for individual product owners or agile product organizations.
I was always somewhat disappointed with the ease of use and approachability of the assessment tool, but I really never had the time to change the delivery format. Nonetheless, there were quite a few people who were actively using it and gaining value from the insights.
But enough background…
I’ve written a lot about product ownership, product backlogs, and user stories over the years. But the other day it struck me that I hadn’t shared something that has worked well for me for many years.
It’s an idea that is coupled to two notions—product backlog refinement and the 3-Amigos metaphor for story evolution.
I noticed in several companies I’ve worked for that teams struggled with getting the stories effectively delivered. There seemed to be, for lack of a better phrase, a lack of ownership in story delivery. That is, stories often missed the mark in functionality, quality, integration, etc. And when we discussed this in our retrospectives, there was a lot of finger-pointing and blaming, but no real solution ideas.
I believe I tried this first at a company called ChannelAdvisor around 2007-2008. So, you can see why I’m surprised that I haven’t thought to share it until now.
I’m writing this around the time when businesses are essentially locked down by Covid-19 and everyone is working virtually. It remains to be seen what types of working habits and new norms will emerge and stick after we recover from this viral attack.
Here I’d like to explore SAFe PI Planning as a planning construct or pattern. Talk about the origination of the idea. Then explore remote PI planning as something that we could do virtually.
But what I really want to focus on is an extension to PI Planning that could nearly negate the need to do it either face-to-face or virtually.
PI Planning – The Intent
The intent of PI Planning is to get a number of teams together for face-to-face planning once a quarter to commit to a body of collaborative work. It’s a scaling tactic that has its roots well before agile hit the mainstream. For example, a similar pattern was shared by Dwayne Phillips in his book The Software Project Managers Handbook, published in 1998. Dwayne called it Cards-on-a-Wall planning. I’ve used the technique to plan larger-scale waterfall projects with 100+ participants.
In a recent blog post by Mike Cohn, he wrote about Establishing a Common Baseline for Story Points. He explores the technique of getting estimators in a room from many teams. Perhaps a pair of individuals per team.
The entire room uses Planning Poker to estimate stories. The focus is on getting all of the folks in the same ballpark when it comes to estimating their stories level of effort.
The idea is not to have everyone become a clone of each other. But to get the story points close enough so that forecasting can be done across the teams. So, consistency without normalization or fixed rules.
Not only do I like this approach, but I’ve also successfully used it with several companies where I’ve coached. Not as an external coach, but as an internal coach. And it works quite well.
I just read an article by Luiz Quintela, otherwise known to me as ‘Q’. I think I met Q when he attended one of my Certified Agile Leadership classes in Dallas. He has since moved to LitheSpeed in DC, but that’s another story.
Anyway…
In the article, Q shares some of his experiences, learnings, and advice related to conducting powerful Scrum sprint reviews. I love all of his advice, so I won’t be nit-picking at any of it.
But I was inspired by his perspective. You see, it was from the point of view of the Product Owner and the team level responsibilities for conducting efficient, effective, and informative reviews. Ones where you get lots of feedback.
But the inspiration was that the role of the ATTENDEE was not really highlighted and that’s where I want to augment the article a bit.
The Role of Sprint Review Attendees
While the Product Owner and team members certainly play an important role in successful Sprint Reviews, the attendees are not simply innocent bystanders. They have a job to do as well. Or a responsibility or a role to play.
I got into a debate with a coaching colleague the other day. Well, debate, disagreement, argument, and other terms could apply. We kept it respectful and, in the end, I believed we agreed to disagree.
I’ll call my colleague, Ken.
We used an analogy as part of our discussion that I’d like to share. Here’s the analogy—
Meniscus vs. TKR?
I’ve got a problem with my knee. I’ve done the web research and self-diagnosed that I have a partially torn meniscus and I want some simple surgery to clean-up my knee and fix the meniscus.
So, I start looking for the best surgeon I could find. The best “knee-person” out there. And I found her. She’s expert at all sorts of knee surgeries from the meniscus to total knee replacements. Having performed thousands of successful surgeries.
I scheduled a visit to explore the surgery. And she runs some tests (X-rays, MRI, etc.) on my knee in advance of our discussion.
I enter the discussion telling the doctor what I need. I even go so far as telling her when to schedule it. As, clearly, I’ve determined what wrong and what to do about it.
She listens patiently but tells me clearly and firmly that I need a total knee replacement. That my knee is irreparable with anything other than that sort of corrective procedure.
I argue with her. And I insist that I simply want the meniscus repaired. I’ve made up my mind AND I want her to do it…
Ask vs. Need
Clearly, in this example the doctor has a decision to make. And I don’t think it’s that hard. The options are:
Tommy Norman is an agile coach in Nashville and he recently posted the following on LinkedIn:
As a Product Owner, do you know how much it costs to run your team per week/sprint?
Having this information can re-frame many of your discussions. When talking to stakeholders you can ask questions like "That would take about 1 sprint, is it worth X dollars to you?". With your teams it can help them understand the impacts of process inefficiencies by showing them how much they cost the company/client.
It does not even have to be super accurate, just a decent representation of the cost. If you have a dedicated team, it's pretty easy. Get a blended salary across team members, add 35% for overhead costs, then figure out how much that comes to per day. Even without a dedicated team you can use rough percentages.
Knowing the cost of delivery is a good first step towards moving discussions next to value delivered and return on investment!
Ever since I read it, I’ve been thinking about the notion. Believe it or not, it’s not something that I’ve thought about much in my agile journey. And I’m stewing over the implications.
While I think it’s a good idea, it might have a Yin and Yang nature to it. Let’s noodle on each side:
I’d like to start off this post with the following excerpt from the ProductPlan website. I think it sets the stage of things quite nicely:
“We’re agile, so why do we need a long-term product roadmap?” I hear this question regularly. At first blush, the terms agile and product roadmap seem like a contradiction, but they’re not. In fact, you should have an agile product roadmap.
In most agile product development organizations, the backlog is used by the development team to track what’s coming next, at least for the next few sprints or iterations. Many agile teams rely heavily on the backlog, as it maps out short-term initiatives. But the backlog in itself is not the roadmap. This post explains why you need both.
Product Roadmap vs. Backlog
A product roadmap is different from a backlog. The roadmap defines a strategic view of where the product is headed over the mid to long term, whereas the backlog defines the product features and initiatives for the near term. The roadmap is tied to the organization’s vision and strategic goals, often for the next 12 or more months. In an agile organization, the roadmap provides guidance rather than a strict project plan.
I also sometimes equate the word Portfolio with Product Roadmap. In my mind, the two are quite synonymous.
