What to estimate when estimating development times 

I’m going to touch a sensitive matter, estimating development times of a feature.
I’m not going to discuss how to estimate, there’s much to say about that and so more on that topic on a future post. What I do want to talk to you about today is what to estimate.

That’s sounds like a silly question, right? We estimate the development time of the future.

Well, the answer,somewhat  surprisingly, is no. We do not estimate just the development stage, we estimate everything we need to get done. 
What’s the difference you may ask, and I reply with a question: What are you estimating ? When are you done?

What does done really mean

If you were like me, you may not have realized how much additional work there is, I won’t list everything, but to get the idea:

  1. The code have unit tests written with a high code coverage
  2. The code passed QA, integration tests, acceptance tests etc’
  3. Code past CR and was refactored accordingly
  4. Code and feature are documented, in code and externally
  5. Feature was deployed! (wait what?)

I’ll first address the last point, code is actually deployed,why is this here? Code does not help anyone when it’s in source control, it only worth something when it’s deployed. If deployment would take you a day of work (preparing the version, editing configuration etc’) then this day of work must be estimated as well, otherwise you’ll end up saying “yes, it done! That is.. I need another day, but I’m finished”. If you need another day – you are NOT done. 

The previous matters are important too!

You may be unconvinced that refactoring and documentation are important. You might also think that unit testing and integration tests are a waste of time. You’re here to write working code!

I say this – in 2017, working code just doesn’t cut it anymore. Code changes, we add new features  and modify existing behavior. Thus, code must be readable (to others too) and easily modifiable (e.g have the safety net provided by tests)

Why estimating everything is important

Imagine the following conversation between Joe the developer and Bob the manager:

Bob: we need to do X, how long would it take you?

Joe: about three days,  another two days for writing unit and another day for an integration test

Bob : Do we really need unit test

Joe: [start talking about testing…]

What’s wrong with this conversation? Who knows best how to write reliable code? Who have the professionalism and responsibility for writing tested working and reliable code?

You were hired based on your knowledge and expertise, you are expected to take the calls and how to do your job. You do not need to ask permission to to a good job, its expected of you.

The responsibly is your! Only you know what to do and how to do it.

Conclusion

The conclusion to be drawn is that it is you, the developer, should decide what you include in your estimation, you should do this based on your definition of done, don’t let yourself be micro managed by given estimation for each of the things you do, but make one estimation that includes everything

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a website or blog at WordPress.com

Up ↑