In Part 1, I wrote about thinking in feature sets and how to quickly create a feature set of—with any luck—smaller features. That’s because features don’t arrive at the same rate and they change in value, during a quarter. Because features change in value and because some feature sets need to deliver value on a more regular […]
Many teams and organizations try to create one-quarter roadmaps. Here are the problems I see: Teams spend a ton of time estimating what they might do and then they select what will fit into a quarter. They feel or are asked to commit to all that work. The product managers and project portfolio managers depend on
I’m almost at the end of the January Practical Product Owner workshop. One of the participants has a problem I’ve seen before. They have a backlog of work, and it’s all tasks. Not a story in sight. I understand how that happens. Here are some ways I’ve seen the tasks-not-stories problem occur: The technical people
When I talk about Minimum Viable Products or Minimum Viable Experiments, people often tell me that their minimum is several weeks (or months) long. They can’t possibly release anything without doing a ton of work. I ask them questions, to see if they are talking about a Minimum Indispensable Feature Set or a Minimum Adoptable
I have a new article up on projectmanagement.com, Continuous Agile Program Planning: Think Big, Plan Small. It’s about how to use rolling wave planning especially for an agile program. If you are a Product Owner or you are responsible for planning what when, and want to learn how to do this, join my PPO Workshop, starting
I’m teaching a Product Owner workshop this week, and I had an insight about a Minimum Viable Product. AN MVP has to fulfill these criteria: Minimum means it’s the smallest chunk of value that allows us to build, measure, and learn. (Yes, Eric Ries’ loop) Viable means the actors/users can use it. Product means you
I am leading the August workshop, Practical Product Ownership, starting next week. I still have room in that workshop. If you struggle with the role of the Product Owner, this workshop is for you. You will learn to deliver what the business needs, with your team. I hope you join us. If you are wondering
When I think of POs and the team, I think of learning in several loops: The PO learns when the team finishes small features or creates a prototype so the PO can see what the team is thinking/delivering. The team learns more about its process and what the PO wants. If the Product Manager sees
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
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. Part 3 was about ranking. In this part, I’ll discuss the product owner value team and how to make time to do “everything,” and especially how to change