For Training, Coaching, and Consulting engagements, please contact me for details on how I can help your organization.

A gentleman named Simon poses this question on a Scrum forum, related to his blog post about his team's Sprint Burndown:
  • "...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 :-)"

Below is my response.


I have coached 3 full scale Scrum transitions where the team had the following characteristics:
  • team doing something markedly "other than Scrum" prior to my arrival and struggling
  • team had zero formal Scrum training and org strongly preferred coaching rather than formal training
  • team doing full on Scrum by the time I left (3-6 months later)

Obviously, doing 3 of these particular types of engagements(Bootstrapping, "Scrum Jump Start," etc) does not make me the foremost expert in coaching these kinds of teams or anything, but the results, given that they had no formal Scrum training, are pretty darned excellent, IMO. But I'm very biased. :-)

When determining what to focus on in coaching the early sprints, I generally do a contextual approach, focusing on what I, as coach, think is the most important thing for the team to get better at. In other words, "conditions on the ground" generally indicate to me where to focus next. In later sprints, I turn this "improvement focus" over to the Scrum team itself.

Analyzing This Burndown

So, if I'm ignoring what all else I would normally focus on, and instead only focus in on your burndown line, with no other context, here is the summary of my observations:
  • IMO, your (actual) line looks very typical for a story point burndown for a relatively new to intermediate team.
  • Questions I would ask
    1. Can you tell me a little more about the story that was added mid Sprint?
    2. If you have people whose area of focus is testing, what are they usually doing for the first several days of the Sprint?
    3. It's generally good practice to get story sizes small, to a few days. Would this be possible for your team?
    4. The (so-called)ideal line, esp from 4/17-4/20, looks weird to me. Did a small story get dropped in that period?
    5. It looks like there was a large amount of closure(story completion) late in the sprint. Did the people focused on closing these stories (testing, PO, whoever) feel hurried, rushed, or nervous that not enough testing was done?
    6. It looks like a small story did not get completed by end of sprint. Normally that's not a big deal -- how did the team take this? (from a morale/emotion standpoint)
    7. You mention a slight feeling of panic when the ideal deviates from the actual line. In your view, does this help the team to "dig in" and focus on "getting to done"?

My Coaching Focus for Bootstrapping Teams

When I'm doing these full scale transitions, whether the teams have almost zero training or not, and I'm analyzing the Sprint Burndown, here is the order in which I generally focus for improvement, as it relates to the Sprint Burndown:

Background: I generally start these new teams off with an ideal task hour burndown, assuming 5-6 ideal hours per day. Later, I might encourage experimentation with other types of burndowns. For these new teams, I have a strong person preference for burndowns instead of burnups, and a very strong preference for hand drawing burndowns on a "big visible chart" vs. using a tool.

A. Coach the team to get good at "getting to Done" for the forecasted items, and don't be afraid to drop/add items.

  • By about Sprint 4, I'd like to see the team be finishing 90+% of the stories that they "accepted into" the sprint (i.e. what they forecast that would be completed), *with* a high confidence that near zero defects will be discovered.
    • This also assumes that a healthy definition of done has been created, whether that be explicitly or implicitly. I push very hard for this level of quality to remain at this level(or higher) indefinitely.
  • As such, I tell the teams that the Sprint burndown probably won't help us much in the early sprints -- the only time it is likely to help us is mid sprint to help indicate that we have taken on way too much for this sprint and it might encourage us to drop some stories.

B. Coach the team to do mild retrospection on Sprint Burndowns

  • After step A, I encourage the team to begin analyzing their burndown for things like:
    • Are we greatly under/over estimating the number of task hours for a sprint?
    • How often are we having to add/drop items?
    • Are there times in the sprint when we feel panicked?
    • Are there times in the sprint when a person is working way hard or way little?
  • I encourage the team to experiment with possibly ways to improve the above.

C. Encourage smoothing out of the Sprint flow by getting stories smaller and/or increasing test automation

  • Generally, these teams experience a situation where the testers(testing focused people) are pretty bored the first few days and pretty panicked the last few days, a holdover from waterfall in my view.
  • It is at this time that I usually introduce *another* burndown, burning down by story points (I make sure both of them are displayed). At this point, with a small amount of creative license, you can usually show that their story point burndown looks literally like a waterfall!
  • I encourage the team to try to smooth out this flow a little by one or both of:
    • Testers begin automating tests early in the sprint, so that they can have a test suite built up for stories before the stories are even "delivered for testing." (This is not always possible for various reasons)
    • Splitting stories smaller so that a couple of stories are delivered for testing earlier in the iteration.

D. Encourage experimentation with Sprint Backlog tasks, different task units, different burndowns

  • At this point I encourage the team to experiment with different techniques, but caution them that
    • a) Let's try to maintain our now smoother flow, and
    • b) Let's not forget that changing too many variables(techniques) at once might decrease the transparency on the effects of these changes
If there is a "micro managing" tone to the above for these teams, it is *intentional* during this bootstrapping period. By about the time the team gets to Step D, I begin moving from "micro managing" to "laissez faire", and then I eventually "sneak off into the sunset," looking back only once, to see the team fully engaged in self organizing themselves.

For non-bootstrapping teams, I use totally different leadership styles! In coaching terms, I take different "coaching stances" based on what the team needs.

Related Articles: