Posted by Robert Merrill on March 2, 2010 under Estimation, Project Set-Up, Software-Intensive Businesses | 
Q: Why were they late for the meeting?
A: They didn’t leave soon enough.
But…they got stopped by a train, and they remembered that they needed to pick up a loaf of bread, and…they have a slow car!
Details like speed limits and the police aside, what do the car, and the bread, and the train have to do with it? The trip took 25 minutes, five of it spent waiting for the train, and five of it in the convenience store, and fifteen of it driving. They left 20 minutes before the meeting, and they were five minutes late.
Well, they didn’t plan on the train or the bread.
Do they ever plan on the train or the bread? Read more of this article »
Posted by Robert Merrill on July 13, 2009 under Agile BA, Agile Methods, Estimation |
If you’re an IT shop considering agile methods, your existing Function Point Analysis (FPA) capability can be a a valuable asset. It freaks many agile-methods advocates out when I tell them, but I routinely follow a user story workshop with a Function Point count.
I already knew FPA when the project-contracting house I worked for went agile. I found I could count the Function Points from a couple of dozen user stories in a half day or less. (Often I discovered some missed stories in the process.) With some project history on hours per FP for the teams I supported, and some multiplication, I had a quick, factor-of-two effort estimate. Flip the factor-of-two uncertainty off of the effort and onto the scope (you know those stories are going to change, anyway), and there’s the core of an agile project proposal. We had about a 1-in-3 close rate, and less than 10% of our projects failed.
Now that I’m consulting for software-intensive businesses and their software teams, the same estimate can be used to request a team and a budget through your established governance process. Read more of this article »
Posted by Robert Merrill on February 6, 2009 under Agile Methods, Estimation |
With just a little bit of effort, the uncertainty in a project estimate drops rapidly. But there comes a point where getting even a little bit more accuracy takes a lot more work (yellow line) and there
“Real Agile teams don’t waste time on X.”
“You can’t deliver quality software without getting X right first.”
My favorite quote from fantasy writer and Christian apologist C. S. Lewis is this: “(The Devil) often sends errors into the world in pairs—pairs of opposites…He relies on your extra dislike of one to draw you gradually into the opposite one. But do not let us be fooled. We have to keep our eyes on the goal and go straight through between both errors.”
A key principle of Agile software development (and much else in business besides) is that of “diminishing returns.” At some point, extra effort in the same direction, even on generally worthwhile activity, is no longer worth it.
I most often find myself talking about diminishing returns when it comes to cost and schedule estimation. “Robert,” someone comes to me, “I have an idea for some software that’s going to save us a million bucks. How long would it take to build it?” Read more of this article »
