Estimation: Introduction

Thu, Mar 1, 2018

A few projects ago one of my team told me he felt software estimation was like trying to guess how long it would take to do today’s crossword. He could be confident about yesterday’s crossword because he’d done it, but today’s crossword … well, he hadn’t seen any of the clues yet. He could give you an average length of time it takes him to complete the daily crossword but was that useful for this crossword?

Not all kanban boards are equal

Not all kanban boards are equal

You have to sympathise with a developer being asked to provide estimates, often knowing that any number given may quickly morph into a committment as far as managers are concerned. You may even be tempted by the #noestimates movement. And yet organisations do need some guide as to cost and timescale. Here are some reasons management may need estimates:

  • Product Size, Performance, and Quality
    • Evalute feasibility
    • Analyse alternatives
    • Determine required capacity and speed of hardware
    • Evalue performance (accuracy, spped, reliability, availability)
    • Quantify resources needed to develop, deploy and maintain
    • Identify & assess technical risks
    • Provide technical baselines for tracking and control
  • Effort, Cost and Schedule
    • Determine feasibility in terms of cost and time
    • Identify & assess project risks
    • Negotiate achievable committments
    • Prepare realistic plans and budgets Evaluate business value
  • Process capability and performance
    • Establish norms for expected performance
    • Identify opportunities for improvemeny

Reasons why software is so difficult to estimate include:

  • Difficulty in stating requirments precisely
  • Little visibility of the product until it’s finished
  • Difficulty in measuring the product and its progress
  • Acceptability crtieria are vague and sbjct to customer taste, or whim

And there are other many factors besides. But some of this is manageable and can be mitigated. And where it can’t be, we can expose the level of risk to take account of it when planning.

Coming next: Estimate, target and committment.

Sources:

  • Estimating software-intensive systems. Projects, Products, and Processes. Richard Stutzke
  • Software Estimation: Demystifying the Black Art. Steve McConnell

Estimation

A series of short articles about software estimation. Here's a list of all posts in Estimation. The first in this collection is Estimation: Introduction

comments powered by Disqus