Log in

goodpods headphones icon

To access all our features

Open the Goodpods app
Close icon
Agile Coaches' Corner - How do you escape the tyranny of the burndown chart?

How do you escape the tyranny of the burndown chart?

07/07/20 • 5 min

Agile Coaches' Corner

In this episode, Professional Scrum Trainer Sam Falco addresses the question: “How do you escape the tyranny of the burndown chart?”

The Problem with Burndown Charts

This was the question a student asked last week. I knew exactly what he meant. I experienced it myself with my first Scrum Team, and I’ve seen it many time since. Teams try to predict every task they’ll have to do during a Sprint, estimate the hours for each, and make sure that the team’s capacity is fully allocated. As the Sprint progresses, they discover new work. Work that was predicted takes longer than usual. The burndown rises instead of falling, or it plateaus. The burndown chart becomes a burden that destroys morale and effectiveness.

After a few Sprints of this experience, teams either abandon the burndown chart or they start playing games to make the burndown “look right.” In both cases, the team loses out on a valuable tool for helping them achieve the Sprint Goal.

Does the Scrum Guide Require Burndown Charts?

To be clear, the Scrum Guide does not mandate the use of a burndown chart. Here’s what it says about tracking Sprint progress:

“At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.”

Tracking total work remaining provides transparency about the team’s progress toward the Sprint Goal. That transparency allow the team to make informed decisions about how to adjust the scope of its work throughout the Sprint. If the team doesn’t know how much forecasted work remains, the Sprint Goal may be placed in jeopardy.

A sprint burndown chart is one way to fulfill the need to sum up the remaining work and make that data visible. So why does the burndown chart so easily become a burden to the team, rather than a tool?

Often, it’s because of a holdover from the mistaken belief that software development can be managed through predictive processes. Even in organizations that recognize the folly of predictive planning on a macro level, teams fall into the trap of thinking they can and should plan every minute of a team’s capacity.

How do we use a Burndown Chart Effectively?

Software development falls into the realm of complexity. Even within a Sprint, we have to allow for emergent understanding of the work. Requirements, understood well enough for the work to begin, become clearer. New work emerges as a result. Teams that have strived for efficiency in allotting their time find that there’s no room to adjust as new information and understanding becomes available.

The secret to avoiding the tyranny of the burndown chart has nothing to do with the burndown chart itself. The secret is to let go of the belief that we can know everything up front and that efficient time usage is a worthwhile goal. Instead, strive for value delivery, select work that the team understands well enough to start on, and don’t strive for 100% utilization. The only thing certain about software development is that it is filled with uncertainty. In Sprint Planning, you need only look a few days into the future, and allow remaining details to arise as work gets underway.

Want to Learn More or Get in Touch?

Register for our upcoming web meetings by visiting agilethought.com/events

See available training courses at agilethought.com/training.

Visit the website and catch up with all the episodes at AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

plus icon
bookmark

In this episode, Professional Scrum Trainer Sam Falco addresses the question: “How do you escape the tyranny of the burndown chart?”

The Problem with Burndown Charts

This was the question a student asked last week. I knew exactly what he meant. I experienced it myself with my first Scrum Team, and I’ve seen it many time since. Teams try to predict every task they’ll have to do during a Sprint, estimate the hours for each, and make sure that the team’s capacity is fully allocated. As the Sprint progresses, they discover new work. Work that was predicted takes longer than usual. The burndown rises instead of falling, or it plateaus. The burndown chart becomes a burden that destroys morale and effectiveness.

After a few Sprints of this experience, teams either abandon the burndown chart or they start playing games to make the burndown “look right.” In both cases, the team loses out on a valuable tool for helping them achieve the Sprint Goal.

Does the Scrum Guide Require Burndown Charts?

To be clear, the Scrum Guide does not mandate the use of a burndown chart. Here’s what it says about tracking Sprint progress:

“At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.”

Tracking total work remaining provides transparency about the team’s progress toward the Sprint Goal. That transparency allow the team to make informed decisions about how to adjust the scope of its work throughout the Sprint. If the team doesn’t know how much forecasted work remains, the Sprint Goal may be placed in jeopardy.

A sprint burndown chart is one way to fulfill the need to sum up the remaining work and make that data visible. So why does the burndown chart so easily become a burden to the team, rather than a tool?

Often, it’s because of a holdover from the mistaken belief that software development can be managed through predictive processes. Even in organizations that recognize the folly of predictive planning on a macro level, teams fall into the trap of thinking they can and should plan every minute of a team’s capacity.

How do we use a Burndown Chart Effectively?

Software development falls into the realm of complexity. Even within a Sprint, we have to allow for emergent understanding of the work. Requirements, understood well enough for the work to begin, become clearer. New work emerges as a result. Teams that have strived for efficiency in allotting their time find that there’s no room to adjust as new information and understanding becomes available.

The secret to avoiding the tyranny of the burndown chart has nothing to do with the burndown chart itself. The secret is to let go of the belief that we can know everything up front and that efficient time usage is a worthwhile goal. Instead, strive for value delivery, select work that the team understands well enough to start on, and don’t strive for 100% utilization. The only thing certain about software development is that it is filled with uncertainty. In Sprint Planning, you need only look a few days into the future, and allow remaining details to arise as work gets underway.

Want to Learn More or Get in Touch?

Register for our upcoming web meetings by visiting agilethought.com/events

See available training courses at agilethought.com/training.

Visit the website and catch up with all the episodes at AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

Previous Episode

undefined - Has COVID-19 Accelerated Agile?

Has COVID-19 Accelerated Agile?

In this week’s episode, Dan Neumann is joined by frequent guest of the show, Quincy Jordan — principal transformation consultant and agile competency lead at AgileThought! Together, they are exploring COVID-19 as an agile accelerator.

In the agile space, there has been a long-time myth that face-to-face is synonymous with colocation and that you cannot have effective agile teams if they are not colocated. However, in the past year or so, many companies have been beginning to consider going to a hybrid remote model. But, when COVID-19 hit, their 12-month transition plans quickly became one-week transition plans. And though this has been very difficult for many, this acceleration due to COVID-19 has actually been a good thing in many cases — which is what Dan and Quincy will be talking about today!

They discuss which types of things got accelerated, beliefs about agility that got challenged due to COVID-19, what the ‘new normal’ post-COVID-19 may look like, and how these changes will be made to be sustainable going forward.

Key Takeaways

Beliefs about agility that got challenged due to COVID-19:

Those people in the agile space that were especially adamant that you cannot have effective agile teams that are remote were shown that it was possible

Some people believed that doing training in a distributed way would bring the quality down — however, the quality of training that is being delivered has not gone down since going remote

What COVID-19 has accelerated:

When pressed, many people are able to do very impressive things and accomplish more than they thought possible

It accelerated ingenuity and creativity

It accelerated the decisions to collaborate with one another as teammates and to quickly come together on a situation to figure out the most effective solution

It helped accelerate clarity on what was truly important to accomplish

It has driven companies to really start embracing business agility a lot more

Agility went from a concept that companies only thought about to a concrete concept that they embraced

Organizations have been focusing on value more due to embracing the agile mindset (and COVID-19 has been pushing this to further bounds)

It has helped push organizations to further their alignment on business agility and focus on the problems that need to be solved

COVID-19 has also accelerated businesses beyond those in software (it permeated into all facets)

Challenges regarding COVID-19 and the acceleration it has brought:

How do we maintain alignment between business and IT in this remote world? (How often do we need to meet? What do we need to be aligned on?)

Video conference fatigue

How do we ensure that the right problems are being solved, that the vision is clear, that the business objectives at hand are clear, and that the teams know how to tie their work to meaningful outcomes for the business?

People don’t adapt as fast as technology

What might the new ‘new normal’ look like post-COVID-19?

There most likely will be more remote work and more emphasis on collaborating remotely

There may be a bigger demand for remote tools (such as digital whiteboards) and they will become even more efficient going forward

People will most likely be more intentional about how they are showing up to video conferences with clearer goals in mind

Mentioned in this Episode:

From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver, by Johanna Rothman and Mark Kilby

The Decision: Overcoming Today’s BS for Tomorrow’s Success, by Kevin Hart

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

Next Episode

undefined - Intent-Based Leadership with Michael Guiler

Intent-Based Leadership with Michael Guiler

This week on the Agile Coaches’ Corner, Dan Neumann is joined by a new guest, Michael Guiler! Mike is an Agile Consultant at AgileThought. He has been an Agile coach for over 13 years now and has tons of experience helping geographically dispersed organizations (both business and technology) transform to better achieve their goals. His focus is on helping organizations learn and apply the values and principles of the Agile mindset to continuously improve.

In this episode, Dan and Mike will be focusing on the topic of intent-based leadership and the key leadership characteristics that allow for intent-based leadership. Mike shares how an organization can begin to take the first steps towards intent-based leadership, how to avoid common pitfalls, and shares his best practical tips and advice on embracing intent-based leadership throughout the organization.

Key Takeaways

What is intent-based leadership? What problems does it solve?

Helps to get the entire team to chip in and no longer wait for approvals and sign-offs

Takes the pressure off of one single leader and unlocks the potential of every employee

The opposite of directive leadership

Changing the pattern from leader-follower to leader-leader

Those in the leadership level are not telling people what to do/how to do it; they are setting goals and directions

The ‘followers’ are engaging their creativity, mind, and intelligence and leveraging those skills and sharing their solutions with the leadership (this gives the organization a great opportunity to learn and exposes leaders to things they hadn’t thought about before)

Getting started with intent-based leadership/Characteristics of leadership to allow for intent-based leadership:

Before the leader-leader pattern can take place a lot of growth has to take place

Keep in mind that this process won’t happen overnight

Immediately begin to address competence — leadership at all levels can’t thrive if your team doesn’t have the skills or knowledge to prioritize and take action

Establish safety — mistakes will happen; it’s how we react to those mistakes that will enable leadership at all levels to thrive or to fail miserably

Use mistakes as a learning opportunity rather than punishing an individual

Be curious and ask good questions from a place of true curiosity

Challenge your preconceived notions of how things have always been done

Embrace new ideas and thoughts — there’s a real chance you’ll learn something!

Allow time for the team to talk out loud

Respect others opinions and encourage others to have their own point of view

It’s hard and will take a lot of time and investment (but it’s money well-spent — the productivity will explode)

It’s important to set guide rails in the technology world

Focus on the goal/outcome instead of the ‘how’; set clear intentions and let the team figure out how

Adopt the “I intend to” language pattern

Mike’s intent-based leadership tips:

Once the competency is established and you’ve gotten your organization thinking about it, it is important to establish safety (without safety people won’t bring their creative-selves or do anything new)

It is key crucial for the team to know what the goals are

Have an “ish” mindset; decisions and actions being taken won’t match yours and that’s OK!

Overcome urges to command and control

Be tolerant of differences and encourage different points of view

Mike’s recommendation to further learn about intent-based leadership:

Turn the Ship Around!: A True Story of Turning Followers into Leaders, by David L. Marquet

Mentioned in this Episode:

Michael Guiler

Agile Coaches’ Corner Ep. 84: “Getting to ‘Finish’ as a Scrum Team with Andrea Floyd”

Turn the Ship Around!: A True Story of Turning Followers into Leaders, by David L. Marquet

Forbes article regarding psychopathology in CEOs

Michael Guiler’s Book Picks:

The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done, by Stephen Denning

Episode Comments

Generate a badge

Get a badge for your website that links back to this episode

Select type & size
Open dropdown icon
share badge image

<a href="https://goodpods.com/podcasts/agile-coaches-corner-111882/how-do-you-escape-the-tyranny-of-the-burndown-chart-5749093"> <img src="https://storage.googleapis.com/goodpods-images-bucket/badges/generic-badge-1.svg" alt="listen to how do you escape the tyranny of the burndown chart? on goodpods" style="width: 225px" /> </a>

Copy