Sign in or 
| Version | User | Scope of changes |
|---|---|---|
| Jan 8 2009, 9:10 AM EST (current) | JonKern | 654 words added |
| Jan 8 2009, 8:57 AM EST | JonKern |
Changes
Key: Additions Deletions
From Alan (a thread on agile project management forum):
Now as to the why-bother:_______________________________________
1. Government reports require (a) a summary and explanation of R&D activities, and (b) an auditable tally of hours spent doing this.
2. To develop some basis for estimation, I need to know how much effort goes into development. My time is very irregular, and I honestly have no idea how many hours are put into programming on any task. I don't know if it varies from week to week. I don't know how long it will take to finish a project AT ALL.
I am suggesting that tracking hours is but one small wee part of estimation... and it must be combined with other, larger pieces of the puzzle to impact estimates. Unless of course, your work is repetitive and non-thinking. Like stamping out license plates.
Though you can certainly have everyone track hours & tasks to the minutest detail... what is the other unit of measure? Lines of code? Features? Story Points? That is, will you strive to be able to predict Lines of Code per hour? Hours per feature? Days per Story Point?
FUN TIP Track your detailed hours for a couple of days every year or so. You might be shocked!
As an aside, I strongly encourage self-introspection and tracking if one has never done it before. In the early 90s I did this for an entire project that I was solo on. I think it was about 4 months of C coding. It was for developing a universal transponder (Air Force and Navy had different "glossary" so I made it work for either "language") messaging system to communicate with and control a missile. I broke down everything into basic types of work... Requirements, Analysis, Design, Code, Test. As I switched from task to task, I was diligent about recording my hours and what type of work it was and added some comments. When I analyzed the pie chart, I discovered I spent a lot more time in testing than I would have guessed.
On an individual basis, if you recorded estimates and actuals for a task, you might be able to improve an individual's ability to estimate similar tasks, or tasks in general (depending on how their estimation skills are to begin with).
But for a team, I am not sure what you would do with a zillion bits of data for all the tasks you do in a week.
I like to keep it simple and I am not very good at estimating. So like to have the team do something like this:
- Look at a list of tasks to complete (in total or for an iteration) and folks make their estimates in hours using "ideal hours". "Uncomfortably" large estimates get broken down into subtasks that can be used to justify the large total.
- Now guess at the ratio of ideal hours (banging out the task) in a day... I'd start at 50%, with the rest being non-task-specific hours.
- Given team size, and task prioritization, you can either determine
- When you will be done with all of the tasks (fixed tasks, variable duration)
- How many tasks you can get done in the iteration (fixed time, variable # tasks)
- At various points in time (either end of the iteration, or every week for example), check accuracy of the "ratio" (aka velocity)
- for the whole team, how close are the estimates to reality? If you are doing way better than the estimates, then maybe your ratio can be bumped up to suit (say to 60%). If you are completing fewer tasks than expected, then reduce the ratio to 40% (for example).
- Recompute the project estimates based on the new ratio
You may have much better techniques -- in which case I would love to learn more about them here.
