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
I see a lot of confusion around velocity in new-to-agile teams. Too many people treat velocity as an acceleration measurement. That is, they expect velocity to increase to some large number, as a stable state. Velocity is a rate of change coupled with direction. When managers think they can measure a team with velocity, they
For many people, agile means an end to all project management. I disagree. I find value in servant leadership in project management. I explain how you can think about servant leadership and agile project management in my projectmanagement.com column this month: Servant Leadership: The Agile Way. If you are looking to increase your servant leadership
I met a team recently who was concerned about their velocity. They were always “too late” according to their manager. I asked them what they measured and how. They measured the burndown for each iteration. They calculated the number of points they could claim for each story. Why? Because they didn’t always finish the stories they
I’ve been teaching workshops these last few weeks. A number of the participants think that they need to create great estimates. I keep hearing, “I have to create accurate estimates. My team needs my estimate to be accurate.” I have found that the smaller the work, the better the estimate. If people work as a team,
Ryan Ripley “highly recommends” Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule. See his post: Pragmatic Agile Estimation: Predicting the Unpredictable. He says this: This is a practical book about the work of creating software and providing estimates when needed. Her estimation troubleshooting guide highlights many of the hidden issues with estimating such as:
I published my most recent newsletter, Creating Trustworthy Estimates, this past week. I also noted on Twitter that one person said his estimates created trust in his organization. (He was responding to a #noestimate post that I had retweeted.) Sometimes, estimates do create trust. They provide a comfortable feeling to many people that you have
I’m happy to announce that Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule is done and available. It’s available in electronic and print formats. If you need a little help explaining your estimates or how to use estimation (even #noestimate), read this book.