customize burndown chart

[jcracchiola]

Towards the end of the sprint, we sometimes pull in "stretch" stories with points to the board to get a head start on versus ending the sprint early with some testing outstanding.

Is there a way to customize the chart to filter those out so the line keeps trending down versus going up?  There was a way to do it in Azure DevOps.

[Bill Sheboy · Accepted solution]

Hi @jcracchiola -- Welcome to the Atlassian Community!

What problem are you trying to solve?

Burndown charts are a diagnostic tool to reflect what has happened and what could happen. Why would you want to alter what has actually happened?  Showing the facts may help the team learn and improve in the future.  For example:

• When the team regularly needs to pull in more work during a sprint, consider how you refine and plan work to better match capacity
• Rather than pull in work to start (but not finish) consider instead splitting down work to pull in what you can finish with the remaining capacity
• As the team improves, you may need to gradually pull in more work during planning to match the increasing team capacity

Best regards,

Bill

[jcracchiola]

Very good points.  This has given me food for thought. I wanted to show what the true burndown looked like without stretch being pulled in.  They don't always finish stretch work.  So that's what I wanted to see.  Thank you so much for responding to me!

[Nic Brough -Adaptavist- · Accepted solution]

I don't think I'd want to do that. 

Several places I've worked at actively reward the spikes caused in burndown by drawing in extra work.  If you did something to stop that showing, then you're a) not telling the truth and b) not able to see where teams deliver above and beyond.

[jcracchiola]

Thanks for responding!  I absolutely want to show the truth but wanted to toggle between burndown charts.

[Bill Sheboy]

Yes, and... to what @Nic Brough -Adaptavist- said.  The dark side of focusing on stretch, above and beyond work is a team might feel incentivized to take shortcuts on how they normally produce quality delivery, leading to other issues.  "Why not, when we get more kudos for extra stuff?"

I think of supporting measures as fitting into two categories: metrics and diagnostics.

Metrics are things which are valuable to observe for the long-term, and so worth checking consistently.  Team capacity is an example metric, as changes in capacity require long-term solutions: adding more people to a team, cross-training them, evolving team responsibilities, etc.

Diagnostics are things which help solve a specific, short-term issue or symptom.  Having stretch work every sprint seems like a symptom, and you are trying to diagnose that by measuring the amount of stretch work in a sprint.  So permanently changing the burn chart for a short-term issue may lead to unintended consequences, such as more stretch work.

[Nic Brough -Adaptavist-]

Yes, that's a great exploration of the value and concomitant costs of thinking too hard about stretch work.  Thanks @Bill Sheboy for that, it's spot on!

What I left out of my answer was that while Scrum welcomes and recognises "going over and above", it is only happy about it when stretch work occurs when the team runs out of committed work. 

In the ideal Agile world, a Scrum team should not be working on anything outside the current sprint until they have every single issue in the sprint "done". 

But in real life, it is not unusual for people to finish at different times.  

Imagine Alice, Bob and Charlie divvy up the current sprint tasks between them based on who has the right skills.  Charlie is really good at X but weak on Y, so when Charlie gets through their tasks, they ask Alice and Bob if they can help.  When the answer is "no", Charlie then should go for a stretch goal, despite Alice and Bob still having stuff to do to meet the sprint goal.  That sprint could easily end with a failure, but also deliver more than expected. 

TLDR: There is absolutely nothing wrong with reaching for stretch goals.  Most Agile trackers are not great at showing it.  Azure DevOps tries, rather than ignoring it, but tends to distort it, leading to people looking at the wrong things.

(I've seen teams using Azure DevOps get rather muddled because they completely lose any focus on what matters - looking at stuff like "we did stretch goals, Yay" has lead some down a path of "never doing the work we actually need to do because we don't get the Yay")

Also, I think I owe Bill several beers for setting me up to legitimately use the word "concomitant" in a post.