Scrum Burndown Patterns [closed]

问题:

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."

回答1:

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

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

回答2:

Pattern 2 on the negative side is "didn't estimate too well".

Here are some burndown charts I've used. Ignore the background pictures - they are there just to entertain the people I work with and have nothing to do with our work otherwise. alt text http://www.atalasoft.com/cs/photos/techtalkgallery/images/16157/425x285.aspx

I love this chart. It's very typical of a good chart we start a little slowly as we shed other tasks, bear down into the work, get interrupted by other things and push to finish.

alt text http://www.atalasoft.com/cs/photos/techtalkgallery/images/16155/425x262.aspx

In this chart we started very steadily and then took off actually finished ahead of time.

alt text http://www.atalasoft.com/cs/photos/techtalkgallery/images/16156/425x264.aspx

In this chart you can see that we started very typically and then a task that looked easy turned out to be heinously hard. I think we ended up halting this sprint and building a new one.

回答3:

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.

回答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.

回答5:

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.

回答6:

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.