5

I work on a lot of small, agile software projects without huge up-front requirements; just ideas that I flesh out over time. Generally, development follows these stages:

  • Prototype (couple of days)
  • Figure out 80% of the features and put them in the backlog
  • Develop the product. Add stuff as you go along.

So there's a huge spike of work added, and then small steps of scope growth regularly.

What I like is that I can change direction fast. What I don't like is that I cannot gauge the rough size of a project before I start working.

What I'm looking for is some process or equation that will help me. "Generally, you add 50% to your project scope after the major estimation part. So factor that in."

How can I gauge the rough size of a project before I start working?

Improve this question
2
  • A few questions before I answer: How big does a project usually end up for you? Is there a big variation? Whats the Min, Max, Median? Also, how often do you/can you release?
    – Ben
    Jun 30, 2012 at 22:28
  • Hard to say @Ben. Projects vary in size quite a lot; some are small, others large. I estimate in points, so each project is completely different. I would say, 3-6 months per release, although I can technically release after any two weeks.
    – ashes999
    Jul 1, 2012 at 1:56

5 Answers 5

Reset to default
5

Measure the work. As you point you work on a lot of different projects. Considering you gather relevant data on past projects you should be able to see some patterns, e.g. most of projects seems to work this way but there are non-standard cases which were driven by one thing or another.

It is hard to answer what brings variability to your work, but you will likely to be able to find root causes easily.

Another idea you may like is sizing not in terms of estimating how much time you need to build a project but how many features / stories / what have you it takes to build the thing. Being able to estimate that a new project is roughly 40 features can tell you very much as long as you know how long it takes to build an average feature (end to end) and how many features you have in progress concurrently. See an example of such approach here.

Again it boils down to measuring your work. Another important flavor here is understanding variability. I mean if time needed to build a work item varies vastly, e.g. anything from 2 to 50 days, average or median won't tell you much unless you have really huge sample of past records.

And finally, if you are able to work with your customers on time and material basis you just get the issue out of the table. In such situation they just buy your time (along with your skills) and it isn't your risk directly when something new pops up.

Improve this answer
3

Read about Cone of Uncertainty - the longer you work with the project the more accurate and precise is your estimate of its duration and size (image from Construx.com website):

construx image of CoU

PMBOK suggests to re-estimate the project every time you have more information about its scope. You start a project with ROM (Rough order of magnitude) estimate and refine it at every milestone. I would also suggest to read Steve McConnel's "Software Estimation: Demistifying the Black Art" - it gives a good summary of existing estimating techniques.

Improve this answer
3
  • Agile is generally not like that. You refine scope as you go along and add a lot of stuff that was previously not well defined.
    – ashes999
    Jul 2, 2012 at 1:19
  • 2
    Actually, @yegor256's answer is more closer to Agile than your comment. Agile is about reducing the uncertainty with short feedback cycle and using this ability to react faster to changes. Clarifying requirements is a small part of Agile
    – Zsolt
    Jul 2, 2012 at 6:22
  • Nope, the graph shows typical waterfall. Would't rely on PMBOOK when discussing agile.
    – Dan
    Jul 22, 2012 at 0:21
2

Pawel talks about measuring your work. This is critical and key. One reason is looking back can help you look forward.

There is a term, often used in agile, called "Yesterday's weather." The concept being that the weather today was probably a lot like the weather yesterday and will be a lot like the weather tomorrow (If you've ever gone to Los Angeles, CA USA this is scarily true). Usually this maxim is used when determining potential velocity of an agile team. If you did 30 points last iteration, then you probably will do about 30 points this one, so don't over book.

The concept can extend beyond this. If you track your projects, than over the course of several projects you can start to see what the norm is for you. You see, no formulae are going to solve the problem. People aren't mathematical formulae. So we can't be easily plugged into universal formulas. What we can do, however, is look at our own history. After doing several projects you will probably find there is are some norms you can look at to determine how much change you have from project inception to launch.

Use your own metrics to determine your own potential.

Improve this answer
2

Agile generally avoids the difficulties of knowing when a large piece of work will be done by not committing to doing them.

If you've got a six month piece of work (based on a finger in the air estimate), pick a small chunk that will give you value by doing it first. It's generally easier to get a handle on how long a small thing will take than a big thing and releasing early allows you to get feedback from customers rapidly.

Chances are, once you've done one or two of these small slices, you'll be getting good feedback that will guide the rest of the work. Don't doggedly deliver what you thought your scope was at the start, constantly re-prioritise feedback against the rest of your potential scope.

We're kind of changing the usual question of "when will we be able to finish by?" with "what is the smallest thing we can do which adds value?".

Provided you're always weighing the value of all possible pieces of work you could be starting against each other and making sure you don't start things that are too big, it's actually not that important to get longer term estimation 'right', it's usually an illusion anyway.

Some more thoughts along a similar track can be found here: http://decision-coach.com/lean-and-real-options/

Improve this answer
2

If you measure projects' actual cost (in time) vs initial estimate (in time or in points) until completion/release (~= 1 / average velocity of product's backlog) over a few of the same team's projects you should see that it doesn't vary much between project and project. Using that factor, you can get a rough estimate of the actual time vs the initially estimated time for future projects with the same team.

The actual time includes added, dropped and modified user stories.

Since the team gives the estimates and does the work, it is important not to mix velocities between teams. If you are getting the change request from clients, try to compare with projects from the same client, as the choice of client will effect the measurements (you can think of the client is a part of the expanded team).
If you see an improvement over time, between projects, (e.g. due to the team getting used to working together (or together with client) more efficiently) then give more weight to the more recent projects.

For a safer estimate, take the minimum and maximum factors (from previous projects) and use them to plot a cone of uncertainty.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.