55054Re: [scrumdevelopment] Re: Burndown charts and late finishers
- May 8, 2012Hi Jeff,What you describe seems to be 'textbook', in that it's exactly as it was put in the scrum guide, and many scrum books. No problems there.What I normally do is try to put focus on finishing stories by doing the sprint burndown on a story points (story in done means points on the chart). I try to leave hours as far out of the discussion as I can, though I do encourage a team to make their tasks as small as possible, preferably so that they can do them within half a day, so there is some implicit time estimation there.In those same teams, which are usually the ones where the stories are still rather large, I often have a burn-up chart of tasks to complement the burn-down of stories. This shows that there is progress, even if stories aren't yet in Done. I've seen that become too much of a focus, though, so I'm not sure about whether that practice is one I should keep up.
Some others don't do the burndown at all and/or burn down stories (not story-points), without assigning points to the stories at all. They consistently have their stories small enough that they can plan based on ability to do 8-10 stories per sprint (for example).WouterOn Tue, May 8, 2012 at 6:30 PM, vercinget_xx <jheinen@...> wrote:
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?
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). During the sprint, the team updates tasks with hours remaining, so they always have a snapshot of how much work is left, and if the trend starts to look like they won't make it, they can adjust their plans in order to meet the sprint goal. I show a story burndown sprint-by-sprint, but not within a sprint. Note that the Team *is* encouraged to tackle the stories one at a time and complete them in sequence. I'd much rather have nine stories "done, done" and one never even touched, than 10 stories 90% completed.
So what do you all use? Within a sprint, do you burn down tasks or stories?
--- In email@example.com, "simonmorris7809" <mozrat@...> wrote:
>> Hello all,
> I mainly wanted to introduce myself to the group as a newbie but also ask a quick question.
> I've been following the group for a while and I find the insights really valuable. Thanks for the time you spend on this community.
> So - in our sprints we consistently start slow and have a big finish. You can see our latest burndown chart here.
> This isn't necessarily a problem as we ship features on time and with the correct quality, but it is always a slight feeling of panic as we drift away from the "Ideal" line.
> I don't really want to push the group to start stronger as we consistently deliver successfully and putting more effort into the first couple of days would just serve to make the chart prettier.
> Does anyone else see this as a warning sign - maybe I should just stop checking the burndown chart in the first half of the sprint :-)
Wouter Lagerweij | wouter@...
- << Previous post in topic Next post in topic >>