Scrum proposes that on every iteration (Sprint in Scrum terminology) you plan a work burndown chart (WBC) [ notice the apparently coincidental simmilarity with WBS: Work Breakdown Structure ] so that time is on the X axis and Y represents the amount of work left in hours.
(This picture was copied from http://www.controlchaos.com/about/burndown.php)
As you have (I suppose) already imagined, the line is a diagonal forming a triangle against the X and Y axis (when planning it is a diagonal, or at least almost a diagonal, what actually happens in the project, if you could measure any points of completion, would look more like a stair going up and down).
Well, so far it seems deceptively simple.
Scrum masters also draw another line including the new items that appear during the iteration. Those were unplanned items and therefore they have to be written somewhere else.
(Taken without permission from: http://danube.com/docs/scrumworks/pro/latest/reports.html)
I was thinking why all those items were drawn below the X axis, since apparently they just pile waiting for someone to fix them, but I was feeling unconfortable with it. When the time on the iteration finishes, how much time is left?
Some Scrum books suggest that you project those 2 lines and they will meet at some point, therefore you will know for sure when this iteration is finished. But they also suggest that several days may go by and you may make no progress, because the originally planned line became flat... So now the lines never touch again.
What if people begin solving bugs first? I think this is one of the best strategies for finishing early, yet the WBC encourages working according to the plan and leaving all those pesky bugs for the next iteration...
Alistair Cockburn has a very good example of a burn down chart and its issues.
So I was wondering if we can know for sure how long it would take, without resorting to the "project the lines" misconception. I really think it is a misconception because all those new issues should be restimated and put in their own iteration and burn down chart. At least that was what Alistair was doing in his example, but I still think it is too expensive, because it is an "after the fact" exploratory system. When faced with an a-priori estimating method and a-posteriori one, I would certainly prefer the a priori estimating method because it would render value before the other method. If after the fact is important, I could always do another estimation later.
How could we estimate a priori the amount of work left? We can estimate a posteriori each and every item and actually fix them in the next iteration, but that iteration will also have some bugs, and so on.
Let us suppose that we empirically determine that for every iteration, we always have half the amount of work left (and for the sake of simplicity, let us suppose it is always half fo the previous iteration).
So if we had 256 hours left in the first iteration, after 256 hours of plentiful work, we still have 128 hours left just to finish was was left on the first iteration. Agilist will complain that the amount of time in an iteration is fixed, while the amount of work is variable during the iteration (we can remove items, not add them, others like to add them), but the problem now is that we finished all items, but new items appeared, because we didn't realize in advance all border cases for example. We will call this time to fix bugs, the re-iteration, in lack of a better term.
We reschedule and we work those 128 hours, only to find out that there are bugs and we estimate them and it amounts to 64 hours left. So we continue to work and this goes on and on. This is the 21st century of version of Achiles and the tortoise.
Can we know in advance how long it will take the fisrt iteration and all its re-iterations?
sum( n = 0 to infinitum, x^n ) = 1 / (1 - x)
See: http://en.wikipedia.org/wiki/Power_series
So if we always have half the work left, sum ( n = 0 to infinitum, 2^n) = 1 / ( 1 - 1/2 ) = 2
That is to say, any iteration it will always take double of what we estimate. Does it sound familiar?
The same can be calculated if we estimate that we have a third of work leff, sum ( n = 0 to infinitum, 3^n) = 1 / ( 1 - 1/3 ) = 2/3
I think this is a very important result, because it eliminates the need to make expensive burn down charts, although of course you still need to decompose the project using a work breakdown structure, identify risks, develop prototypes, use iterations, etc. The only advantage is that given a few iterations you can gather some statistics and predict accurately how long the project will take.
But remember you need to finish those iterations first in order to gather meaningful statistics, otherwise all that estimation is just wishful thinking.
I was thinking why all those items were drawn below the X axis, since apparently they just pile waiting for someone to fix them, but I was feeling unconfortable with it. When the time on the iteration finishes, how much time is left?
Some Scrum books suggest that you project those 2 lines and they will meet at some point, therefore you will know for sure when this iteration is finished. But they also suggest that several days may go by and you may make no progress, because the originally planned line became flat... So now the lines never touch again.
What if people begin solving bugs first? I think this is one of the best strategies for finishing early, yet the WBC encourages working according to the plan and leaving all those pesky bugs for the next iteration...
Alistair Cockburn has a very good example of a burn down chart and its issues.
So I was wondering if we can know for sure how long it would take, without resorting to the "project the lines" misconception. I really think it is a misconception because all those new issues should be restimated and put in their own iteration and burn down chart. At least that was what Alistair was doing in his example, but I still think it is too expensive, because it is an "after the fact" exploratory system. When faced with an a-priori estimating method and a-posteriori one, I would certainly prefer the a priori estimating method because it would render value before the other method. If after the fact is important, I could always do another estimation later.
How could we estimate a priori the amount of work left? We can estimate a posteriori each and every item and actually fix them in the next iteration, but that iteration will also have some bugs, and so on.
Let us suppose that we empirically determine that for every iteration, we always have half the amount of work left (and for the sake of simplicity, let us suppose it is always half fo the previous iteration).
So if we had 256 hours left in the first iteration, after 256 hours of plentiful work, we still have 128 hours left just to finish was was left on the first iteration. Agilist will complain that the amount of time in an iteration is fixed, while the amount of work is variable during the iteration (we can remove items, not add them, others like to add them), but the problem now is that we finished all items, but new items appeared, because we didn't realize in advance all border cases for example. We will call this time to fix bugs, the re-iteration, in lack of a better term.
We reschedule and we work those 128 hours, only to find out that there are bugs and we estimate them and it amounts to 64 hours left. So we continue to work and this goes on and on. This is the 21st century of version of Achiles and the tortoise.
Can we know in advance how long it will take the fisrt iteration and all its re-iterations?
sum( n = 0 to infinitum, x^n ) = 1 / (1 - x)
See: http://en.wikipedia.org/wiki/Power_series
So if we always have half the work left, sum ( n = 0 to infinitum, 2^n) = 1 / ( 1 - 1/2 ) = 2
That is to say, any iteration it will always take double of what we estimate. Does it sound familiar?
The same can be calculated if we estimate that we have a third of work leff, sum ( n = 0 to infinitum, 3^n) = 1 / ( 1 - 1/3 ) = 2/3
I think this is a very important result, because it eliminates the need to make expensive burn down charts, although of course you still need to decompose the project using a work breakdown structure, identify risks, develop prototypes, use iterations, etc. The only advantage is that given a few iterations you can gather some statistics and predict accurately how long the project will take.
But remember you need to finish those iterations first in order to gather meaningful statistics, otherwise all that estimation is just wishful thinking.
It is very interesting that Agile Methods are fusioning with the Balanced Scorecard: http://www.agilejournal.com/articles/articles/the-agilev-scorecard/
No hay comentarios:
Publicar un comentario