Scrum Burndown Patterns

Question

I'm in a 10 person team working on a large legacy code base with a less than ideal product owner. Our backlog is in pretty bad shape and large epics have frequently been breaking our sprints. The team also struggles with its definition of done - some members write unit test religiously, others don't, sometimes depending on time available.

So, I've been seeing some interesting burndown patterns, and I'm wondering which patterns others are seeing and what they mean.

Pattern 1:

#
# # 
# # #  
# # # #     
# # # # #   
# # # # # #
# # # # # # #

• Positive explanation: "All good."
• Negative explanation: "Too good to be true. What's really going on?"

Pattern 2:

#
#
# #
# #     
# # #   # 
# # #   # #
# # # # # # #

• Positive explanation: "This was way easier than we thought, let's pull in more stories."
• Negative explanation: ??

Pattern 3:

#
# # # #
# # # #  
# # # #     
# # # # #   
# # # # # #
# # # # # # #

• Positive explanation: "Not sure about this work at first, then turns out easier than we thought."
• Negative explanation: "Not enough progress, let's stop writing unit tests to get 'done' on time."

Answer 1

This is recognized around our office as the "Ah, crap! I forgot about that." burndown:

    # # #
    # # # #
    # # # # #
    # # # # # #
#   # # # # # #
# # # # # # # #
# # # # # # # #

Answer 2

One problem with burndowns is that changes in scope are mixed in with progress against scope.

In your example 2, a possible explanation is... holy smoke, I probably shouldn't have waited until the end of the iteration to start this risky story/task... it's alot more effort than I expected!

In example 3, you may have added scope early or discovered that work is more effort than expected (e.g. task is estimated at 4 hours one day, then 4 hours the next after 8 hours of work and discovery that the task is much harder).

I prefer burn-ups to burn-downs for this reason... it disassociates the scope changes from the progress into two lines - one scope and one remaining work, so you can see the impact of scope change more clearly.

Answer 3

Here it's often like that:

#####
#######
########
#########
#########
#########
##########

Positive: Delivery on time.

Negative: Too big backlog items or too many backlog items started at the same time from the beginning.

Answer 4

My view is not to take burndown charts too seriously. They are an indicator. In the end it is about if you completed a story or not.

Are you having effective retrospectives at the end of your sprints ?

Are retrospective actions followed up on ?

If you find that people don't write unit tests religiously make them do it ( if that is your team standard). Agree on a common definition of done and stick to it. See definition of done

Having an agile process like SCRUM needs constant inspection and adapting.

To me it looks like there are problems but your team is not addressing those problems. If the product owner is less than ideal, issues related to this should come up in your retrospectives so you can avoid it in the next sprint.

if you have epics you can always break them down, re-prioritise and re-plan them.

Answer 5

Here's one I haven't seen here yet. It happened on our last sprint.

#
##
###
#####
#############
##################
###################
####################

It's the "we made better than expected progress on our first tasks, then thought were were ahead, slacked off, then had to push hard catch up at the end or risk slipping a feature."

Lesson learned: Burndowns are great for tracking past efforts, but aren't necessarily representative of your future progress.