Scrum issue #35 :: Any estimate is better than no estimate

“What do you think, how big is it?” or “How much time do you need to solve it?” – I will ask any of the two questions often, especially when urgent new story or task is coming into the sprint backlog during active sprint.

The story behind is: I worked with a team sometime ago and noticed a very strange pattern in their Scrum board. There were some tasks estimated ‘0h’ into their current sprint backlog, but those were not moved to the ‘done’ column. For me a task set to ‘0h’ remaining time means ‘done’ and I pointed that quickly. It turned out, those were items in progress: support requests, bugs or any other complex/unknown tasks which cannot be precisely estimated. At first I thought we could somehow breakdown those items and estimate the effort but most were already set at a level of just one task. For example if was a bugfix request the needed steps would be: to analyse/debug and then fix. And for complex systems no developer would be able to precisely estimate how much effort would be needed to debug and identify the cause of the issue. Even nowadays I usually hear a statement like ‘If we are lucky it could take less than an hour, if not – it could take weeks’… Not good.

The worst part is that those ‘0h’ tasks are hidden time sinks and could block some team members for weeks. In my observations this is one major reason why waterfall projects usually fail to deliver on time. I’ve seen developers stay blocked for months struggling with an issue that simply could have been ‘rejected’ after being identified as a huge time sink in less than a week.

So instead of estimating time to delivery we first estimate time for ‘spike’. For non-practitioners ‘spikes’ are time-boxes dedicated to just analyse, identify the complexity and estimate a certain issue. The time-box could vary but in my experience should not be bigger than 2-3 days. If there is still no progress after that, we contact the product owner and either offer another spike or think about workaround to be introduced in less time. Another alternative – the issue could be rejected or flagged as ‘not so important’, and the client just advised not to use the specific scenario in which it occurs.

After spiking, the issue could turn out to be huge and require more time than one sprint to be entirely developed/fixed. In that scenario we split it in terms of value and deliver as much as possible to the end of the particular sprint. The remaining part is up to the product owner to prioritise.

Another possible outcome is to identify the issue as being blocked by another issue. It is put on hold then and the Product owner decides what the priority is as usual.

For a complex/unknown story, the developers usually assign a lot of hours to the tasks (just to have some buffer). This is somewhat ok – but it is important to reduce the remaining hours accordingly as the level of knowledge increases. Don’t just log hours – look at the ‘time remaining’ value on a daily basis and adjust it. This way there is a much better transparency on the progress and the real risks for delivery by the end of the sprint are clearly visible.