Re:“It’s done, there is no way back. We tried, we failed”
by nstart on Thursday August 13, 2015 @04:04AM
(#10052776)
The most common time the 8 hours policy breaks down (insert rage face here) is when going bug hunting on non straight forward bugs. I just got out of a 5 day bug hunt where the fix was literally changing a 10 to 40 (so, 1 character change). The debugging process to realise this was painstaking elimination of possible causes. I eventually stumbled on the root cause by mistake when I out of frustration just switched an unrelated boolean flag to see if I could get a laugh out of what happened next. These tasks can really screw up an entire dead line. I have a policy on those which is two steps:
1) Daily report in the morning SCRUM style of what was tried, and what's going to be tried next. 2) After a full working week, reassess everything and try and understand where you are going with this.
Rinse and repeat. Basically the estimate is set at 5 full working days whenever you work on an obscure problem. But it's not a hard deadline. It's just a hope that it'll work out by then and a mild mental aid of giving something to work towards.
Hah, I like this. Every level up that sees it is also a potential for more scope creep, as each person will have their own vision of what's being produced.
One of my favorite estimating guidelines from a mentor was that development tasks are either 2, 4, or 8 hours. If it's more than 8 hours it can be broken up into smaller tasks.