2023-01-31
1370
#agile and scrum#collaboration and communication
Ian Khor
157526
Jan 31, 2023 â‹… 4 min read

What is a burndown chart?

Ian Khor Senior Product Manager @ Octopus Deploy | Ex-lawyer | Enthusiast of all things Agile, LEAN, JTBD, and RICE

Recent posts:

Pivot Or Perish: Why Product Agility Determines Market Survival

Pivot or perish: Why product agility determines market survival

Great product managers spot change early. Discover how to pivot your product strategy before it’s too late.

Bartosz Jaworski
Jul 2, 2025 â‹… 6 min read
Thatch Nguyen Leader Spotlight

Leader Spotlight: Human empathy in the age of AI, with Thach Nguyen

Thach Nguyen, Senior Director of Product Management — STEPS at Stewart Title, emphasizes candid moments and human error in the age of AI.

Marta Randall
Jul 2, 2025 â‹… 6 min read

Where your focus is actually going (and how to get it back)

Guard your focus, not just your time. Learn tactics to protect attention, cut noise, and do deep work that actually moves the roadmap.

Kayode Adeniyi
Jul 1, 2025 â‹… 4 min read
Leader Spotlight: Rumana Hafesjee

Leader Spotlight: Data-driven vs. human-centered decision making for product design, with Rumana Hafesjee

Rumana Hafesjee talks about the evolving role of the product executive in today’s “great hesitation,” explores reinventing yourself as a leader, the benefits of fractional leadership, and more.

Marta Randall
Jul 1, 2025 â‹… 8 min read
View all posts

One Reply to "What is a burndown chart?"

  1. This is a good article on using the “burn down” chart method to track progress on projects large enough to use them.

    And this approach, along with sprints, works well in many mass manufacturing scenarios.

    Speaking from decades of experience both managing software projects and being a hands-on developer/team lead/architect, this is a problematic way to manage software projects.

    Software engineering is quite different than manufacturing, though there are some useful commonalities.

    Manufacturing is creating N quantity of a single item, assembling it in a deterministic process of known parts and known, repeated, labor processes. There is little that is not predictable. Those who assemble the items are not engineers, but technicians.

    Software engineering is creating a number of different items, much of which comes from creating new components or altering existing components. This is nondeterministic, requires creativity, and (most importantly to this article’s context) the time to complete any part of the process is too dependent on a number of variables, as to be predictable.

    Software development is best managed by tracking the major milestones (NO SPRINTS), and team leads that know if their team members are being productive or not. Coders are typically not considered creative or professional, but developers, engineers, and architects in software are professionals who are both scientists and artists.

    Many software shops have learned that the principles echoed in the “Agile Manifesto” are useful in software engineering, and work when applied to the unique characteristics of each software shop. But many have learned the hard way that using the various “agile methodologies”, especially when managed by non-engineer project managers, are costly, lead to low quality (at best) and failed projects (at worst).

    I believe what is presented in this article has some useful principles that, when applied properly, will benefit a software project. Those useful principles do not differ much from how successful software projects were managed before the “agile methodologies” entered the software business, pouring molasses in the gears of success.

Leave a Reply