One of the more difficult activities which new developers are faced with, is determining what they should do, how long will it take and when will it be done.  Being able to handle this will make any developer more efficient, desired and respected on any project they choose to work on.  Why can I say this?  If you know what you are going to do, you by extension know what you are doing, which is a big win.  If you know how long something will take you both prove you have a good grasp of what you are doing and can plan time at home where your significant other can give you the "Honey do" list.  Last, know when something will be done, implies both the time and requirements elements, so that not only do you know when, but what dictates success.

 

What this all means is that no one will be wondering about you, your work can be measured and expected, and you get done when you say you will.  So how does this work?

 

Here is the 2 elements I use when evaluating work I (or others) need to do.  First is determining what you need to do and estimating:

That's your over all time estimate.

 

The second element is how to use this to report status.  One of my work friends promotes the 3 questions:

 

Using the task estimating model, you should be able to answer the first 2 questions easily, the last should be part of the definition of the task, your exit criteria.

 

Reporting status becomes easy, just report your tasks, the estimate, your real start and end dates, and voila.  It's interesting that current development collaboration tools, such as TFS (Team Foundation System) readily support this model, and in fact make the status report easy, so that Project Management does not have to pester you if you teach them to use the tool.

 

Good luck with that!