Evidence Based Scheduling - handling hidden tasks, concurrent tasks?

Question

I've sort of been trying EBS on my personal project tasks, but two things have come up a couple times I'm not sure how to handle.

1 - I find some hidden task(s). I thought it was going to be 6 hours to do task X, but turns out that requires a new Ant build task, which requires libray ZipBlahBoo, which I have then get into ivy, which requires some investigation into the XML parsing library versions each uses. I want to note these new tasks in my list, but that disrupts the estimation impact. I might have taken 6 hours for the actual original task, but there were another 8 hours in hidden tasks.

2 - I'll often have tasks that are mutually dependent. I need to update the Foolet service, but that also means updating the API, which means updating the Mock Foolet service used in unit tests. I've got each of those called out as 2 hour tasks, but I don't do them serially, I do them concurrently because the system won't work until it's all done. Let's say the set of tasks takes 15 hours and I know overall I took 13 hours, but I don't really know all that well how much of that 13 hours any of the specific tasks too. From an EBS point of view, how do I track the time it took to complete each task?

Any suggestions?

Answer 1

1. That's a case of not being good at foreseeing all the hidden tasks, so you should add all these hours. Basically, you do 14 hours for that, including the stuff you aren't foreseeing right now. Of course, you still estimate "6 hours", and then apply the multiplier computed from past evidence.

2. Well, that's tough. I suggest you either estimate, and live with that, or stop splitting such tasks.

Answer 2

1. Evidence based scheduling should work best if you just charge all the hidden sub-task hours to the task that spawned them. This way, it will begin to transparently factor these occasional overruns into your overall expected performance and therefore produce better projections.

2. You're splitting too finely. Updating a test harness to account for an interface change shouldn't be a separate task from the interface change itself, unless the test harness is a separable product.