You must estimate the work

Maybe this seems like an obvious thing to some people, but there are some things which aren’t estimating that we mistake for estimating. 

Example one, we apply a rule of thumb.  For example, the development team estimates 10 weeks of work and we apply a rule which says testing will be 50% of development, thus 5 weeks.  Now, whether the real work is 5 weeks or not becomes lost because we didn’t estimate.

Example two, we staff rather than estimate.  You’ve got a certain number of projects and a certain number of people, therefore we think all people must have a project to work on.  Not so.  Unless you estimate the work, you have no idea whether the number of people you put on the project is too many or two few.

Example three, we extrapolate.  We estimate 100 test cases, know the average cost is 1 hour per test case and therefore estimate 100 hours of work.  This is estimating, but it’s problematic in that we now only know how our total project cost is found from test cases.  That doesn’t mean all 100 hours will go to test case execution, some of it goes to management, some of it goes to data mining, some of it goes to writing up bugs, and so on.

Unless you set an expectation around the actual work to be performed (in LEAN, setting standard work times) then you lack any basis to evaluate whether you did it faster or slower.  You can’t draw a value stream (well, you can’t draw a value stream with data boxes on it) if you never get any real data around what each process step is taking.  And you can’t get any real data around the cost of each step unless you set yourself up to do that work in a reasonable amount of time.

If you’re just putting people in chairs, then Parkinson’s law is going to do a number on your productivity.

Leave a Reply

Your email address will not be published. Required fields are marked *