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
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
In Part 1, I talked about the way POs think about the big picture and the ranked backlog. The way to get from the big picture to the ranked backlog is via deliverables in the form of small (user) stories. See the wikipedia page about user stories. Notice that they are a promise for a conversation.
I just posted the dates for the next Practical Product Ownership workshop: Deliver What Your Customers Need. It starts Aug 23, 2016. You need this workshop if: You are having trouble doing everything in your PO role, you might be trying to do too much. See Product Manager, Product Owner, Business Analyst? You are having
I keep seeing talks and arguments about how the portfolio team should manage the epics for a program. That conflates the issue of project portfolio management and product management. Several potential teams affect each project (or program). Starting at the right side of this image, the project portfolio team decides which projects to do and
If you’ve read Reasons for Continuous Planning, you might be wondering, “How can we do this?” Here are some ideas. You have a couple of preconditions: The teams get to done on features often. I like small stories that the team can finish in a day or so. The teams continuously integrate their features. Frequent features
In agile, we separate the Product Owner function from functional (development) management. The reason is that we want the people who can understand and evaluate the business value to articulate the business value to tell the people who understand the work’s value when to implement what. The technical folks determine how to implement the what.
Many product owners have a tough problem. They need so many of the potential features in the roadmap, that they feel as if everything is #1 priority. They realize they can’t actually have everything as #1, and it’s quite difficult for them to rank the features. This is the same problem as ranking for the