5

In Joel's blog on evidence based scheduling he suggests making estimates based on the smallest unit of work and logging extra work back to the original task.

The problem I'm now experiencing is that I'll have create object A with subtask method A which creates object B and test all of the above.

I create tasks for each of these that seems to be resulting in ok-ish estimates (need practice), but when I go to log work I find that I worked on 4 tasks at once because I tweak method A and find a bug in the test and refactor object B all while coding it.

How should I go about logging this work? should I say I spent, for example, 2 hours on each of the 4 tasks I worked on in the 8 hour day?

Improve this question

3 Answers 3

Reset to default
1

I wonder if it is not the fault of the way you are organizing your tasks. As I read it you are creating tasks at the level of code. ie a task for Class A, and perhaps subtasks for method B,C.

Try setting your tasks at a higher level of abstraction ( ie UseCase / functional behaviour / Use story level ). If it requires you to change 4 areas of code to achieve one outcome, that is one task. Also it will save you having to "refactor" your tasks when you change your technical approach.

Depending on your SDLC approach you need to ensure that these task levels are correctly size ( generally the more agile your approach the smaller the size ought to be )

Improve this answer
1

I'm not intimately familiar with evidenced-based scheduling, but it sounds like your tasks are too small. You should try to make your tasks more encompassing. Although one of the examples from Joel's post is "write a subroutine foo", I think that's way too small. I find I work better if a task is a visible, deliverable thing, and my subtasks are the pieces of it. As an example, a task might be to correct a defect in an output file, and this defect is entered in the defect tracking system. My subtasks might be to review the code (especially if I'm not familiar with it), write test cases to confirm the defect (and help ensure that it's fixed), apply the fix, update the documentation, and run any smoke tests to ensure that I didn't introduce any other defects in the system before I push the changes up.

I'd also recommend focusing on one task at a time. If you find something else to do, pause, write it down (or enter the defect in the bug tracker or add a //TODO comment or...), and resume what you were doing. When you have finished your current task, prioritize the newly found tasks, make sure they are tracked per your team's process, and make sure they are done by the best people to do the job.

Improve this answer
1
  • well I do have them as subtasks of a larger deliverable task, my problem is how I switch back and forth between the subtasks. Making the small subtasks seems to work well for making accurate time estimates, but not as well for logging it.
    – xenoterracide
    Apr 5, 2012 at 0:50
0

You have a couple of ways you can go about this sort of thing. If you spot a problem in something you have worked on before, you could:

  • Fix the problem as a part of the task you are working on - refactoring dependencies to ensure your current task completes successfully.
  • Log a bug, and provide estimates to fix it in your issue tracker. Then prioritize the task so that you either,
    • complete the dependent task first, or
    • complete the current task with tests showing an error, then go on to fix the bug you've logged, and on completion wait for tests in both cases to pass before checking it all in.

Personally I'm not in favour of leaving things in error while fixing other things. If the bug is new, and it's something in a dependency, then I simply fix the problem as a part of the task that I am working on. Once a task is complete, it's complete, and if it has a bug, it has a bug. Hopefully your testing avoids this situation, but if your tests still pass, then the prior task should be finished, closed, and left alone.

If you have made your tasks very granular, then you need to ensure that you have dealt with dependency items first. If you have two tasks with common dependency, you might complete the dependency in one task so that it is available when you move onto the next task. So by effectively completing tasks, You shouldn't need to worry about jumping back and forth between two tasks. It should just be a case of logging a bug, or fixing it as a necessary part of the thing you might be working on at the time.

Yes, this could all mess with your estimates, but if this is something that happens often and you are using Evidence Based Scheduling, then your estimations will all work out fine (statistically) after a short while, so I wouldn't worry to much about it. :-)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.