You’ve started thinking in feature sets. Maybe you’ve experimented with rolling wave plans inside one quarter, so you can change and replan as you need to support your project or program. You’ve discussed flow-based roadmapping as a way to create MVPs and MVEs, release smaller value more often so you can make better decisions. You […]
If you need to plan more often than once a quarter, how do you know how to replan? Instead of incurring the time and cost when you bring everyone together, consider the Product Value Team. (In past writing and presentations, I’ve called this the Product Owner Value Team. I am trying to change my term
One of my clients was trying—valiantly—to make their quarterly planning sessions work. They prepared, getting the big hotel room. They had plenty of supplies. The planning even went well. However, within two weeks, their plan had no relation to reality. That meant that for the next ten weeks, the product owners were “on their own.”
In Part 1, I wrote about thinking in feature sets so everyone could see smaller chunks of work. (If you can see them, you might be able to plan for smaller and deliver smaller.) In Part 2, I suggested smaller rolling waves than an entire quarter (two months, or preferably one month) so people could
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
Knowledge, Risks, and Guarantees One senior manager in an organization trying to use agile told me about his problems, “We still need to know when the project will be done. We can’t afford the risk of missing the deadline. When we spent all that time on requirements, the team knew what they were doing. We
If you’ve been following the conversation, I discussed in Part 1 how I like agile roadmaps and gross estimation and/or targets for projects and programs. In Part 2, I discussed when estimates might not be useful. In Part 3, I discussed how estimates can be useful. In Part 4, I discussed #noestimates. Let me summarize
When we think about the discussion about estimates and #noestimates, I have one big question: Where do you want to spend your time? In projects, we need to decide where to spend our time. In agile and lean projects, we limit the work in progress. We prefer to spend our time delivering, not estimating. That’s
In Part 1, I discussed order-of-magnitude estimates and targets. In part 2, I said how estimates can be misused. In this part, I’ll discuss when estimation is useful. Here are several possibilities: How big is this problem that we are trying to solve? Where are the risks in this problem? Is there something we can