Estimates

In response to Kevin's post, here are some of my thoughts...

In my short career as a software consultant, I have found estimating how long it will take you to do something is an everyday struggle. Not only do others want to know how long it will take you to add that widget and need it by yesterday, but you need to be able to pace yourself as you work through your sub tasks and make sure you will be able to get everything done when you said you would.

To me, any talk of estimating work boils down to a few key skills:

1. Understanding what needs to be done
2. Understanding that the above will change several times before you are done and is probably incomplete to start with
3. Being able to abstract the work into smaller more manageable pieces
4. Using past experience to estimate how much effort (not time) is involved in doing each piece
5. Figuring out how much effort and time you have and how they relate
6. Being able to reevaluate what you have done and what you have left to do so that you can keep track of how much is left and be proud of what you accomplished.

There are numerous technical and general business oriented methodologies used to try and tame this hairy process. At a previous client, they loosely followed the Scrum agile methodology for their project management. I don't claim to know the in's and outs of the formal process or remember everything we did, but here is how it basically broke down:

The development process was broken down into sprints (~4 weeks in length) where the goal of each sprint was to finish a small subset of the final functionality leaving the system in a stable state which could be presented to the stakeholders. Prior to starting each sprint we would decide on a list of "backlog" items that would be included; each backlog item corresponding to some medium to large logical unit of work.

After the backlog items were chosen, we would work through each, identifying key sub tasks and estimating how long they would take. When we put in the time to really think through the stuff or had any confidence in the requirements the sub tasks would end up being fairly small (2 - 16 hours). When we didn't know what we were going to do they ended up being things like "Develop Web Service - 40 hours".

During the sprint we were supposed to update our assigned sub tasks each day with the time remaining we felt it would take to finish the work. In an ideal world you would be able to graph the total time remaining of all tasks in the sprint over the length of the sprint from XXX to 0. In reality people didn't update their numbers often and due to new requirements, being held up by other teams or pour initial estimates, the numbers would hardly ever go down by the same amount as time passed.

Finally, each day we had a Scrum meeting which is supposed to be a <= 15 minute meeting, with everyone standing so as to not get too comfortable where everyone would quickly highlight what tasks they were working on, what they had accomplished, any holdups they had encountered and notify anyone else of issues that they would be impacted by. This I actually really liked as a process for small to medium sized teams. It leaves everyone with a basic sense of how the work is progressing, who they need to work with on issues and gives the manager a good way to stay on top of things which are causing delays. In reality it often degraded into a 30+ minute meeting in a conference room where people felt like they needed to give too much detail and go sidetracked by discussions that only pertained to a few key people and not the whole team.

All in all, I think the methodology helped more than it hurt. By pushing people to estimate their time it caused them to think through there work in advance. This helps people to avoid problem areas ahead of time and identify future concerns. Daily status meetings, when done correctly, allow everyone to be aware of the progress the team was making and share in finding solutions to problems. Finally, the whole process encouraged a fair amount of accountability. Your name was on tasks that everyone could see. You had to tell everyone what you had accomplished yesterday and what you were doing today. You had to see how your estimates compared to the actual time and saw by how much the team as a whole missed there estimates.

..........

As far as estimating my day to day work is concerned, I think spending the time to break your larger tasks into smaller ones (<>. Small tasks are easy to focus on, are finished relatively quickly and can be shown as progress toward an end goal. Large tasks seem more impressive when finished, but result in mismanaged time and little encouragement along the way.

The best thing I have found as an informal method came out of our scrum meetings. In order to not sound like a broken record each day, I was forced with dividing my work into small chunks that could be understood by other developers, business analysts, etc. By spending a few minutes prior to our meeting each day and coming up with a list of 1-4 tasks I wanted to accomplish (and thought I could) that day and of those that I was unable to finished yesterday ..... I always had a simple To-Do list of work. Each task was small enough that I could fit the whole thing in my brain, explain it to a coworker without a lot of background and gave a huge sense of accomplishment when crossed out. The fact that these had to be said in front of a group of peers forced them to not be too small ("Turn on Computer") and not too big ("Finish Web Services") but a nice compromise that said what I was doing and could actually be done ("Complete policy processing code").

wow that was a long post. hopefully someone (anyone) will read it :-p