Product Owners and Learning, Part 1

When I work with clients, they often have a “problem” with product ownership. The product owners want tons of features, don’t want to address technical debt, and can’t quite believe how long features will take.  Oh, and the POs want to change things as soon as they see them.

I don’t see this as problems.To me, this is all about learning. The team learns about a feature as they develop it. The PO learns about the feature once the PO sees it. The team and the PO can learn about the implications of this feature as they proceed. To me, this is a significant value of what agile brings to the organization. (I’ll talk about technical debt a little later.)

AgileRoadmap.copyright-1080x794One of the problems I see is that the PO sees the big picture. Often, the Very Big Picture. The roadmap here is a 6-quarter roadmap. I see roadmaps this big more often in programs, but if you have frequent customer releases, you might have it for a project, also.

I like knowing where the product is headed. I like knowing when we think we might want releases. (Unless you can do continuous delivery. Most of my clients are not there. They might not ever get there, either. Different post.)

Here’s the problem with the big picture. No team can deliver according to the big picture. It’s too big. Teams need the roadmap (which I liken to a wish list) and they need a ranked backlog of small stories they can work on now.

Example.AgileRoadmapOneQuarter In Agile and Lean Program Management, I have this picture of what an example roadmap might look like.

This particular roadmap works in iteration-based agile. It works in flow-based agile, too. I don’t care what a team uses to deliver value. I care that a team delivers value often. This image uses the idea that a team will release internally at least once a month. I like more often if you can manage it.

Releasing often (internally or externally) is a function of small stories and the ability to move finished work through your release system. For now, let’s imagine you have a frictionless release system. (Let me know if you want a blog post about how to create a frictionless release system. I keep thinking people know what they need to do, but maybe it’s as clear as mud to  you.)

The smaller the story, the easier it is for the team to deliver. Smaller stories also make it easier for the PO to adapt. Small stories allow discovery along with delivery (yes, that’s a link to Ellen Gottesdiener’s book). And, many POs have trouble writing small stories.

That’s because the PO is thinking in terms of feature sets, not features. I gave an example for secure login in How to Use Continuous Planning. It’s not wrong to think in feature sets. Feature sets help us create the big picture roadmap. And, the feature set is insufficient for the frequent planning and delivery we want in agile.

I see these problems in creating feature sets:

  • Recognizing the different stories in the feature set (making the stories small enough)
  • Ranking the stories to know which one to do first, second, third, etc.
  • What to do when the PO realizes the story or ranking needs to change.

I’ll address these issues in the next posts.

If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.

Tags: , , , ,
Previous/Next Posts
« »

5 Comments

  1. Petrik

    I would love to see a blog post about the frictionless release system. At our current company we’re trying to move to CI and eventually CD but there are many things we need to learn / change / improve so any information is welcome.

    Reply
    • johanna

      Hi Petrik, Thanks for telling me. I will finish the Product Owners and Learning series and then do the frictionless releasing post. (I think it’s just one, it might be more.)

      Reply
  2. Tom Hussey

    “I see these problems in creating feature sets” … Is there also a problem with managing dependencies between features that appear in different feature sets? (or is there an assumption that there aren’t any?)

    Reply
    • johanna

      Hi Tom, oh, thanks for reminding me (grin). When I work with POs, I help them see if they have curlicue features. Curlicue features indicate interdependencies. Often, the interdependencies arise from not having feature teams.

      When I help people create really small stories, and they realize they need someone/or some other team to implement a really small story, that’s when they realize they are probably not organized “right” for their project or program. I’ll think about where to put this gem in this series.

      Reply

Trackbacks/Pingbacks

  1. Product Owners and Learning: Part 2 – Technology Up2date - […] Part 1, I talked about the way POs think about the big picture and the ranked backlog. The way…
  2. “Laugh it up, fuzzball!” - Han Solo - Magnus Udbjørg - […] Owners and Learning – Part 1, Part 2, Part 3, Part 4 & Part […]
  3. Five Blogs – 9 July 2016 – 5blogs - […] Product Owners and Learning, Part 1 Written by: Johanna Rothman […]

Submit a Comment

Your email address will not be published. Required fields are marked *