Tuesday, August 6, 2013

Software Estimating Tips / Tricks / Traps

This post is broken down into the following areas
  1. The presentation given at
       360Stack on Aug 6, 2013
       Houston TechFest on Sept 28, 2013
       Software Craftmanship North American on Nov 9, 2013
       Agile Leadership Network - Houston on Feb 20, 2014
       PMIHouston - June 8, 2015
  2. The highlights from the presentation, in case you don't want to read the slides
  3. Resources
  4. Questions that were asked during the presentation
  5. Backstory to the presentation
  6. Cross-links
  7. Feedback and comments

Software Estimating: Tips for upping your SWAG

I'd love to hear your feedback

9 Tips for improving your software estimating abilities

  1. Determine if you are supposed to be estimating or hitting a target
  2. Use units that are consistent with the estimates underlying accuracy
  3. Explicitly express the uncertainty in your estimates
  4. Collect and use historical data
  5. Count when possible; compute when you can't count
  6. Do a pre-mortem
  7. Envision someone else (not you) doing the work
  8. Remember the most commonly forgotten project related tasks
  9. NEVER TRY. Do or do not. Manage your commitment and your implied commitment with vigilance. 


Questions from presentation

  • Could you talk about larger projects, like bigger than six months. Do these techniques still apply?
     The "Demystifying the Black Art" book is absolutely structured to discuss which techniques work at which stage of the project. It also categorizes by project size, what stage in the project, and type of project (iterative or sequential).
  • How do you build in scope creep into your estimate?
    Put that into your explicit range as a +2 months for 20% new features, or if you are unsure about the client have a +6 month or whatever risk quantification. 
  • Do I charge for estimates?
    I wish clients would pay for it because it is a lot of work, but sadly, no I don't. 
  • Estimating based on historical data... isn't that like your stock prospectus "Past performance doesn't guarantee future performance"?
    Not really, the market is driven by so many factors, but this isn't the case, this is YOUR historical data. Unless your team has had a complete overhaul of people, or you have done a Matrix like download of new skills, your team's historical data is an incredible accurate model to base similar projects against. But beware of the intuitive trap, use concrete numbers (size, number of stories, number of screens, etc) to do the comparison. If you are using intuition or memory for the comparison, you will likely not get a good estimate. 
  • How much effort do I put explaining this [the concepts in this presentation] to the client?
    I make sure it comes out in my language. First I clarify if I'm creating an estimate or hitting a target. If I'm creating an estimate, I make sure that I use estimate and commitment in the same time frame.  Something like the estimate is 5 months, but I can commit to you that I'll deliver something of value, that is less than the whole thing, to you in three months. Give me 2 weeks to get into it, and I can give you a good sense of what that might be. 

    The overall trap, is that you want to avoid committing at the big end of the cone, when it is most uncertain and unclear about what the project is about. 
  • Do you give one estimate to the employees, and an later estimate to the client, so that way the employees finish early?
    Personally, this question made me uncomfortable.  My answer is no, I see no reason to withhold information or give misinformation to my team. As an Agilist, my client is involved all the time. I show them something every week. There is no question to anybody, either on the team or the client, the exact status of the project and if we are on target or not. When my team makes a  commitment, we treat that as such. I can ask my team "I have your word that we will complete all of the things that we say by the time that we said".  If your team is not at a place to give their word, to make that commitment, then it is up to you to determine how you would manage your team and client interactions.
  • Tangent : The research and the book "Drive" by Daniel Pink was mentioned (and I highly recommend it)
  • If estimates are non-negotiable, what happens when you get a new piece of information?
    If you get new information that improves the clarity of the project, and moves you farther into the cone, then by all means, re-estimate. Remember you *should* be re-estimating several times before the end of a project. Estimates are not fixed. 

Backstory on this presentation

I had a great time presenting last year at 360Flex, and I wanted to present again. I knew that since the feel of the conference was changing to be less Flex centric, I wanted to make sure to choose a topic that was generic enough.  At the time, I was working on this crazy estimate with 100+ highly detailed requirements. 

While I was doing this estimate, I thought "I really have no basis for what I'm putting down here.... I'd like to know how to make better estimates" 

Also at the time, I was reading several psychology related books, and the overwhelming consistent information coming from these books, that unless you are an expert at a given task (10K applied hours) that your intuition can easily lead you astray. I was certainly not an expert at estimating and I was completely guessing at what the effort was. 

Therefore, I declared that "Estimating" was going to be my topic, and threw my hat into the ring, so to speak. Immediately I started researching the topic, just in case I got picked. 

The field of estimating is WAAAAAAAY overwhelming. PhD disserations, $100K dollar software packages, complex statistical math, and simple tricks were un-navigably abundant  in my initial research. I decided to narrow my talk to the psychology of estimating; simple things that can to to trick your brain to get you to better estimates. 

I was reading "Thinking Fast and Slow" at the time, and it seemed to fit perfectly with this decision. Half of this mighty book was about professional forecasters and how our environment influences our estimates. It seemed like the perfect match for this presentation.

I started out with an outline based on that book, then I was going to fill it in with details from "Demystifying the Black Art". Once I started reading "Demystifying", that was it... the book was perfectly suited to my presentation. The new outline literally flowed out in an half hour sitting.

It was also fortuitous, because as I was talking to people about the cognitive biases associated with estimating, I got frequent warnings about informing people how poorly their brain works. With these warnings, I was pretty sure that presenting about cognitive biases, it would likely be at best, completely ignored, and at worst, a pretty sizable flame war.

So after several practice presentations to my wife, my mom, the most experienced estimator on the Twin Technologies team, and finally all of  the Twin Technologies team, I have the presentation that is presented to you at 360Stack.

One nice discovery that came about this from this presentation is the "How good of an estimator are you" slide, with the 10 questions. When I was in college, my professor gave us these 10 questions as a quiz. He counted the score as part of the grade, which I wasn't pleased with, as I was average for this test, which was 30%. It was comforting to discover  that 30% is average, even if he didn't mention that fact, and even 20 years later.

Cross links to this blog / presentation

Feedback and comments

  • Fantastic volume of content crammed into a 50 minutes session."
  • Very practical advice on how to estimate projects. One of my favorite sessions."
  • best preso ever!"
  • All around really great! Slides, topic, presentation, speed, q&a, all good
  • The content was well thought out! You did the #1 rule in presenting (tell 'em, tell 'em, tell 'em).
  • Getting access to the slides, opening my eyes to the importance of spending extra time on estimates