The Product Roadmap is Not the Project Portfolio

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 when for the organization. The product owner value team decides which features/feature sets to do when for a given product. That team may well split feature sets into releases, which provides the project portfolio team opportunities to change the project the cross-functional team works on. The product development team (the agile/lean cross-functional team) decides how to design, implement, and test the current backlog of work. When the portfolio team gets in the middle of the product roadmap planning, the product manager does not have the flexibility to manage the product backlog or the capabilities of the product over time. When the product owner value team gets in the middle (or doesn’t plan enough releases), they prevent the project portfolio team from being able to change their minds over time. When the product development team doesn’t release working product often, they prevent the product owner team from managing the product value. In addition, the product development team prevents the project portfolio team from implementing the organizational strategy when they don’t release often. All of these teams have dependencies on each other. The project portfolio team optimizes the organization’s output. The product owner value team optimizes the product’s output. The product development team determines how to optimize for features moving across the board. When the features...

How to Use Continuous Planning

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 with continuous integration creates an environment in which you know that you have the least amount of work in progress (WIP). Your program also has a steady stream of features flowing into the code base. That means you can make decisions more often about what the teams can work on next. Now, let’s assume you have small stories. If you can’t imagine how to make a small story, here is an example I used last week that helped someone envision what a small story was: Imagine you want a feature set called “secure login” for your product. You might have stories in this order: A person who is already registered can login with their user id and password. For this, you only need to have a flat file and a not-too-bright parser—maybe even just a lookup in the flat file. You don’t need too many cases in the flat file. You might only have two or three. Yes, this is a minimal story that allows you to write automated tests to verify that it works even when you refactor. A person who is not yet registered can create a new id and password. After the person creates a new id and password, that person can log in. You might think of the database schema...

Reasons for Continuous Planning

I’m working on the program management book, specifically on the release planning chapter. One of the problems I see in programs is that the organization/senior management/product manager wants a “commitment” for an entire quarter. Since they think in quarter-long roadmaps, that’s not unreasonable—from their perspective. There is a problem with commitments and the need for planning for an entire quarter. This is legacy (waterfall) thinking. Committing is not what the company actually wants. Delivery is what the company wants. The more often you deliver, the more often you can change. That means changing how often you release and replan. Consider these challenges for a one-quarter commitment: Even if you have small stories, you might not be able to estimate perfectly. You might finish something in less time than you had planned. Do you want to take advantage of schedule advances? In the case of too-large stories, where you can’t easily provide a good estimate, (where you need a percent confidence or some other mechanism to explain risk,) you are (in my experience) likely to under-estimate. What if something changes mid-quarter, and you want more options or a change in what the feature teams can deliver? Do you want to wait until the end of a quarter to change the program’s direction? If you “commit” on a shorter cadence, you can manage these problems. (I prefer the term replan.) If you consider a no-more-than-one-monthly-duration “commit,” you can see the product evolve, provide feedback across the program, and change what you do at every month milestone. That’s better. Here’s a novel idea: Don’t commit to anything at all. Use continuous planning....

7 Tips for Valuing Features in a Backlog

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 project portfolio. You can apply similar thinking. Once you have a roadmap, use these tips to help you rank the features in the backlog: Should you do this feature at all? I normally ask this question about small features, not epics. However, you can start with the epic (or theme) and apply this question there. Especially if you ask, “Should we do this epic for this release?” Use Business Value Points to see the relative importance of a feature. Assign each feature/story a unique value. If you do this with the team, you can explain why you rank this feature in this way. The discussion is what’s most valuable about this. Use Cost of Delay to understand the delay that not having this feature would incur for the release. Who has Waste from not having this feature? Who cannot do their work, or has a workaround because this feature is not done yet? Who is waiting for this feature? Is it a specific customer, or all customers, or someone else? Pair-wise and other comparison methods work. You can use single or double elimination as a way to say, “Let’s do this one now and that feature later.” What is the risk of doing this feature or not doing this feature? Don Reinertsen advocates doing the...

Three Tips for Product Owners

As I work with more clients on their programs, I see that what might work for a product owner for a team does not work for a program. In a program, if the product owner is shortsighted, does not take advantage of agile/lean for updates, and does not have small features, the program loses momentum. Here are my three tips: 1. Take the big picture perspective. When the product owner (or, in this case, a program product owner) creates a several quarter rolling wave roadmap the teams can see the product direction. This helps the teams see avoid bad product decisions that might inadvertently prevent the product from taking a direction the PO would like. There is a challenge with this. Teams can rarely, if ever, commit to an entire quarter’s worth of work. That’s okay. The roadmap is a wishlist. The roadmap informs and guides the product development. Teams need detailed backlogs. 2. Use agile and lean to update the roadmap often, as in every couple of weeks. I know of just a couple of teams who can plan for up to three iterations and not replan. Some teams can plan for two iterations, some for one. Even if you can complete features according to a one-quarter roadmap, the product owner needs the ability to change the ranking of the remaining features. As the teams finish features, it’s the product owner’s job to accept the features, or not. And, it’s the product owner’s job to update the one-quarter roadmap—and maybe the multiple quarter roadmap. The bigger the product, the smaller the features/stories need to be. I’m working with some...