- Hello, When I first looked at the graph, I thought your actuals were actually ... Sorry for having left this thread for so long - have been away for a while.Message 1 of 15 , May 22, 2012View SourceHello,
When I first looked at the graph, I thought your actuals were actually *too* close to the ideal. The line *should* actually go up before it goes down, because no amount of analysis will ever result in knowing all the tasks and the effort required in advance.
But then I realized your burndown is showing the completion of stories, not tasks! So that left me pondering, do most you you all burn down stories within a sprint, or do you burn down tasks?Sorry for having left this thread for so long - have been away for a while.I'm also interested in the stories and tasks questions. It's worth noting that the Scrum team I am a member of is fairly immature in experience of the methodology but we're keen on improving.We only use stories but I'd be interested in using tasks if we can see a clear benefit.
The way I've always done it is, after the team commits to stories in the planning meeting, they then brainstorm all the tasks and estimate them in hours. Summing all the hours then provides a rough cross-check of the committment (i.e. if the task hours sum to about 50% - 70% of the total working hours available, you're probably within the ballpark. If the total hours exceed 70% of the available time, then the team is probably over-committed).We use a system of:* Working out our total committed rate over the length of the sprint.* Reserving 20% of that capacity for admin, pruning, overrun* Committing to stories in order of priority until we get to the remaining 80%So - we use a padding system of 20% and its encouraging that others use the same method.Thanks for the response.Simon