I've started to notice a recurring pattern to our team's burndown charts, which I call a "bowstring" pattern. The ideal line is the "string" and the actual line starts out relatively flat, then curves down to meet the target like a bow.

My theory on why they look like this is that toward the beginning of the story, we are doing a lot of debugging or exploratory work that is difficult to estimate remaining work for. Sometimes it even goes up a little as we discover a task is more difficult once we get into it. Then we get into implementation and test which is more predictable, hence the curving down graph. Note I'm not talking about a big scale like BDUF, just the natural short-term constraint that you have to find the bug before you can fix it, coupled with the fact that stories are most likely to start toward the beginning of a two-week iteration.

Is this a common occurrence among scrum teams? Do people see it as a problem? If so, what is the root cause and some techniques to deal with it?

  • 7
    Could it be that some team members just don't update the backlog regularly, then towards the end of the iteration they just wake up and mark a lot of tasks done at once? Commented Nov 17, 2011 at 21:35
  • 4
    @PéterTörök - This is typical programmer behavior when 'busy' work, like status reporting, is ignored when there is real productive work to do. While this isn't supposed to happen in Agile/Scrum, in my experience, it still does.
    – jfrankcarr
    Commented Nov 17, 2011 at 21:43
  • If you have a task which will take one developer two weeks, and is worth 10% of the iteration's points, when do you mark those points off? Also, are you as quick to decrease the total remaining if a job is less complex once you start looking into it?
    – pdr
    Commented Nov 17, 2011 at 22:07
  • Good comments, everyone. The team members give their updated estimates in the daily scrum, and I do the busy work of putting it into the tool, so it's updated regularly. Decreases are a lot more common than increases. Commented Nov 17, 2011 at 23:55

4 Answers 4


If you're still meeting the target, I don't necessarily see this as a problem. You met your target!

Part of the reason for short sprints/increments is to keeps the team focussed: this batch of work should be finished by the end of this sprint.

If you have a long iteration, the amount of time stretches out like the horizon: the deadline never looms until you're right under it.

Also, more loose ends may be tied up towards the end of the sprint. Again, this is fine. The short two week sprint has helped resolve these things before they pile up into a big six month panicky rush mountain.


If it is consistent and predictable, I don't see it as being a problem.

Unless you detect that this is causing your quantifiable project harm, are there not more pressing issues to spend time considering? If there are not, I am envious of you :)


One way to address this issue is to create smaller stories and realistically add research & debugging tasks. What my team has done is to break down stories so that they generally don't last for any more than two to three days.

If you create small stories that can be "consumed" rapidly and hold the usual daily meetings, your team should be able to quickly whittle away at the amount of work remaining in the sprint. Your burndown chart should start to reflect this state as well. Naturally, not all stories can be broken down like this, but if most of the stories are small, you'll probably see a more linear chart. I'm assuming that the devs will be closing tasks & stories as they wrap up work. My team usually does this before our daily scrum - the scrum master collects small fines from those that forget!


Your situation is typical. Many scrum masters are hunting for great burn down chart. I see such behavior as mistake that leads to many problems later. Burn down chart is an early warning indicator.

If on your Y axis are story points then flat line is correct. Stories are typically longer than 1 day and oonly once they are completed, the line is going down.

If you have hours on your Y axis then such pattern says your team is either not updating remaining time or they are not able to estimate it.

Even such pattern the team is still able to deliver, then it means they are able to estimate sprint capacity correctly. And this is what really matters. To estimate so they are able to accomplish what they promised.

Different burn down patterns are described in interesting way at http://www.scrumdesk.com/is-it-your-burn-down-chart/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.