At the beginning of every iteration our whiteboard is covered with "not started" stories estimated in IDEAL HOURS. On a daily basis we update these estimates to keep track of each task's progress. I think we are doing it wrong. The original estimates are in ideal hours and our daily "re-assessment" in ELAPSED TIME. This seems inconsistent, right?! How would you measure your progress towards the end of the sprint?
-
How many hours a day do you work ? At sprint planning, how many ideal hours a day did you expect to have during the sprint ? And what do you mean by ELAPSED TIME, is it time that elapsed while you were working on a task or just time that elpased ?– DavidCommented Aug 26, 2011 at 13:21
-
FogBugz looks at the original estimate and teh actual time to complete and then helps you with the predictions.– JobCommented Aug 26, 2011 at 17:29
Add a comment
|
2 Answers
We never update our original estimates. Instead we just also log total time spent on the ticket. This gives us better information so we can review are estimation process and drive out any issues. We also check to make sure our estimates are as close to consistent in terms of actual effort.
Reestimating tasks during sprint is non-sense. It will just spoil burndown chart and it will not change commitment you already did.
Anyway in my opinion whole point of "estimating" tasks is waste. What you will get by estimating these tasks?
- Will the estimate will make your product better?
- Will the estimate increase the quality of the product?
- Will you make your product faster if you spend time on doing estimates?
- Will your product be better if you do more estimation?
I don't think so => task estimation doesn't bring any value.
Now what will happen if you don't do estimates?
- Does it mean that you will not be able to track the work progress?
- Does it mean that you will not estimate?
- Does it mean that you will not be able to do commitment?
No because tasks are created from user stories which are already estimated. Commitment is done on user stories so it doesn't matter what is estimate of tasks. Only important thing to track during sprint is amount of completed user stories which can in case of burndown chart still be represented in amount of delivered "story points" or any other unit used to estimate user stories. Tasks should be small and it doesn't matter if small mean day or 3 hours. Developers should be skilled enough to create such tasks without need for estimation. It means that task estimation doesn't remove any value.
If we go to lean principles any process which doesn't bring any added value and can be removed without loosing any value is a waste and should be eliminated.
But perhaps you get some value from task estimation - every team can implement Scrum little bit differently. If you doubt you can use great feature of agile. You can simply try it in one sprint and if it doesn't prove itself useful you can return to task estimation.
answered Aug 28, 2011 at 20:28
-
You could use the total of estimated hours as a check to see if there's time enough in the sprint to perform them.– KwebbleCommented Aug 28, 2011 at 20:46
-
@Kwebble: And what would you get from it? It doesn't matter once you did commitment. You will see that at the end of the sprint anyway. Commented Aug 28, 2011 at 20:50
-
The tasks are created during sprint planning. If you know at that point not all user stories can be delivered the expectation of the PO can be adjusted at the start. It's probably more useful for teams that are still learning to estimate their velocity.– KwebbleCommented Aug 28, 2011 at 21:15
-
@Kwebble: I don't think that expectation should be adjusted. That is the point of the commitment - the responsibility. Especially for new teams it is important to learn that commitment doesn't change. Btw. their estimation can be wrong and they can still fulfill the commitment but they will know it only by their progress later in the sprint not by their "estimates" = guessing. Velocity is not estimated, velocity is measured and computed from passed sprints. But you are right that new team should try Scrum as is with estimation and improve it later after they are more familiar with the process. Commented Aug 29, 2011 at 6:27
-
Good insight, guys! This is still giving me some trouble, could you please take a look at the comment I just added to the thread spawn from the original question. Comments much appreciated!!!– PomarioCommented Aug 30, 2011 at 17:24