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.
I have a new article up on agileconnection.com called The Case for #NoEstimates. The idea is to produce value instead of spending time estimating. We have a vigorous “debate” going on in the comments. I have client work today, so I will be slow to answer comments. I will answer as soon as I have
I have an article up on agileconnection.com. It’s called How Do Your Estimates Provide Value? I’ve said before that We Need Planning; Do We Need Estimation? Sometimes we need estimates. Sometimes we don’t. That’s why I wrote Predicting the Unpredictable: Pragmatic Approaches for Estimating Cost or Schedule. I’m not judging your estimates. I want you to consider
I am doing a google hangout with Marcus Blankenship on April 10. We’ll be talking about estimation and my new book, Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule. The book is about ways you can estimate and explain your estimates to the people who want to know. It also has a number
For years, we bought the cone of uncertainty for estimation—that is, our estimates were just as likely to be over as under. Laurent Bossavit, in The Leprechauns of Software Engineering, shows us how that assumption is wrong. (It was an assumption that some people, including me, assumed was real.) This is a Gaussian (normal) distribution.
Many organizations create teams by their architectural part: front end, back end, middleware. That may have worked back in the waterfall days. It doesn’t work well when you want to implement by feature. (For better images, see Managing the Stream of Features in an Agile Program.) Pierce Wetter wrote this great article on LinkedIn, There is
As I write the program management book, I am struck by how difficult it is to estimate large chunks of work. In Predicting the Unpredictable and Manage It!, I recommend several approaches to estimation, each of which includes showing that there is no one absolute date for a project or a program. What can you do?
I’m writing part of the program management book, talking about how you need to keep everything small to maintain momentum. Sometimes, to keep your work small, teams move from iterations to flow. Here are times when you might consider moving from iteration to flow: The Product Owner wants to change the order of features in