Part 1 was about how the PO needs to see the big picture and develop the ranked backlog. Part 2 was about the learning that arises from small stories. This part is about ranking.
If you specify deliverables in your big picture and small picture roadmaps, you have already done a gross form of ranking. You have already made the big decisions: which feature/parts of features do you want when? You made those decisions based on value to someone.
I see many POs try to use estimation as their only input into ranking stories. How long will something take to complete? If you have a team who can estimate well, that might be helpful. It’s also helpful to see some quick wins if you can. See my most recent series of posts on Estimation for more discussion on ranking by estimation.
Estimation talks about cost. What about value? In agile, we want to work (and deliver) the most valuable work first.
Once you start to think about value, you might even think about value to all your different somebodies. (Jerry Weinberg said, “Quality is value to someone.”) Now, you can start considering defects, technical debt, and features.
The PO must rank all three possibilities for a team: features, defects, and technical debt. If you are a PO who has feature-itis, you don’t serve the team, the customer, or the product. Difficult as it is, you have to think about all three to be an effective PO.
The features move the product forward on its roadmap. The defects prevent customers from being happy and prevent movement forward on the roadmap. Technical debt prevents easy releasing and might affect the ease of the team to deliver. Your customers might not see technical debt. They will feel the effects of technical debt in the form of longer release times.
Long ago, I suggested that a specific client consider three backlogs to store the work and then use pair-wise comparison with each item at the top of each queue. (They stored their product backlog, defects, and technical debt in an electronic tool. It was difficult to see all of the possible work.) That way, they could see the work they needed to do (and not forget), and they could look at the value of doing each chunk of work. I’m not suggesting keeping three backlogs is a good idea in all cases. They needed to see—to make visible—all the possible work. Then, they could assess the value of each chunk of work.
You have many ways to see value. You might look at what causes delays in your organization:
- Technical debt in the form of test automation debt. (Insufficient test automation makes frictionless releasing impossible. Insufficient unit test automation makes experiments and spikes impossible or quite long.)
- Experts who are here, there, and everywhere, providing expertise to all teams. You often have to wait for those experts to arrive to your team.
- Who is waiting for this? Do you have a Very Important Customer waiting for a fix or a feature?
You might see value in features for immediate revenue. I have worked in organizations where, if we released some specific feature, we could gain revenue right away. You might look at waste (one way to consider defects and technical debt).
Especially in programs, I see the need for the PO to say, “I need these three stories from this feature set and two stories from that other feature set.” The more the PO can decompose feature sets into small stories, the more flexibility they have for ranking each story on its own.
Here are questions to ask:
- What is most valuable for our customers, for us to do now?
- What is most valuable for our team, for us to do now?
- What is most valuable for the organization, for us to do now?
- What is most valuable for my learning, as a PO, to decide what to do next?
You might need to rearrange those questions for your context. The more your PO works by value, the more progress the team will make.
The next post will be about when the PO realizes he/she needs to change stories.
If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.
| Reference: | Product Owners and Learning, Part 3 from our JCG partner Johanna Rothman at the Managing Product Development blog. |
