I like to be efficient. I like finishing my work quickly, without wasting time, money, or energy. But it’s also important to be effective—working on what matters most. One of the legacies of waterfall approaches is that too often, our focus is on efficiency and not effectiveness. Efficiency is how fast you can do something. […]
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.
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
In the first part of this series, I said I liked order-of-magnitude estimates. I also like targets in lieu of estimates. I’ll say more about how estimates can be useful in part 3. In this part, I’ll discuss when I don’t like estimates. I find estimates not useful under these conditions: When the people estimating are
After the article I referenced in Moving to Agile Contracts was published, there was a little kerfuffle on Twitter. Some people realized I was talking about the value of estimates and #noestimates. Some folks thought I was advocating never estimating anything. Let me clarify my position. I like order-of-magnitude estimates. I don’t hire people without