No estimates in Scrum

6:36 PM

I found this video last week, I thought it was going to be a radical one but it wasn't. I agree with many of his points.










He explains something that all developers and product managers know: it is really hard to estimate in software development. For many decades we have been trying to find a way without success. The agile community decided to use story points.  The idea of using story points was to hide the time statistic or as he explains: to obscure time. This will remove pressure from the team and will let them concentrate in delivering value. It apparently worked but the managers  were still pushing for estimates. 

This pressure forced  many teams to start mapping story points against time (e.g. one story point equals one hour of ideal work). So we have now a process to create story points and a process that uses days to estimate. We just added work to our estimation. Do we really want this?
 
He brings a second problem to the table: Velocity. Velocity has been transformed into a way of evaluating performance. Velocity was initially seen as a ratio between ideal time/actual time. It tells you a status so that you can understand your team. In theory you can not modify it. It is like a property. But why do people gets confused? The problem is that sometimes you may be able to modify the system that is creating impediments and obstacles to the team. This is possible to change but not the developers. As if they were the whole time reading magazines and wasting their time (well, you might find one or two like that in your life.

He continues and agrees that we DO need estimations but because we know that they can just not be perfect, we should try to find the easiest way to estimate them, he proposes counting stories. Before watching this video I tried it with my team and the result was really good. The only thing that I think he forgot is that we should try to make our stories as small as possible, this will help make the calculation easier.  

But, what if we find stories that seem to be really difficult to implement or that we just don’t know how to solve?. For this, we can try to use Spikes (which are kind of stories used only for research and in some cases for small prototypes). We can restrict Spikes to a certain length (e.g. 1 day) and this will make them “smaller”.  In my experience this method is faster and can be well understood.







0 comments