BURNDOWN CHARTs SPEAK
- Prateek Nigam
- Jan 5
- 11 min read
Updated: Jan 5
Most of the product development teams, at least in the software industry know about Burndown chart and almost all the teams using Scrum are capturing burndown but how many of them really care that their burndown is telling something. Do they take it seriously and adapt? If not then start doing it.
We can’t say that a particular trend on burndown chart is for a specific problem always, there is no such mapping. If two different teams are getting the same trend on the burndown chart, there is possibility that it’s because of two entirely different reasons. Teams have to identify their specific problems by having discussion and the specific solutions to those problems.
In my years of experience working with 50+ Scrum teams, I have seen various trends of burndown and based on that I am sharing my perspective on their potential reasons behind a trend and what actions can be taken by different accountabilities/roles in Scrum to deal with it.
This article will give you a direction to think (not a readymade solution) to figure out the specific reason behind your burndown’s trend. Communication is the key.
Here we go...
BURNDOWN CHARTS' PATTERNS
STARVING FOR WORK
Potential Reasons:
It’s your 1st sprint and you are starting with few ready items for development. It’s OK.
Usually, Product Backlog isn’t having sufficient items.
Demand is lesser than capability.
PRODUCT OWNER: Make sure that Product Backlog has sufficient work to maintain the flow of value and items are ordered and refined for upcoming 2-3 sprints to avoid any surprises within a sprint.
DEVELOPERS: It’s good to capture and present the data about actual work time and waiting time for work. It could be an eye opener for your managers, PO, customer or whoever is paying.
If it’s Sprint 1 or 2 then it could be a good practice to add research items, if available (Commonly known as Spikes) in Sprint Backlog for better visibility.
SCRUM MASTER: This is a Product Management issue. Ensure that Product Owner understands the importance of Product Backlog Management, Stakeholders management and Coach and enable PO with techniques for effective Product Backlog management.
LATE START - SMALLER INCREMENT
Potential Reasons:
Items were not refined – Discuss in Retro.
No clarity on priority hence late decision making.
Last Sprint stretched to deliver the planned work, Flexible Timeboxing.
Sprint started late due to holidays – Ignore
PRODUCT OWNER: Seeing a long vertical line, we can’t say that Product Backlog isn’t having items to work on. Ensure that Product Backlog is ordered for faster decision making for planning, highest ordered items are well understood by developers and required details are added, keep Product Backlog refined in advance for upcoming 2-3 sprints.
DEVELOPERS: There is no challenge or surprises while delivering the forecasted work. Leverage refinement to develop understanding on upcoming items in advance, vertically slice and estimate items to ensure their readiness before planning.
SCRUM MASTER: Facilitate the discussion in Retro (if needed – for less mature or new teams) and ensure that team is able to identify the reason behind the delay.
If required, coach team and ensure that refinement activities are not considered as optional, Cadences are respected, Timeboxing is well understood and followed. If the root cause of delay is external, ensure that team skilled to collaborate with anyone who is critical for improvement and gets it resolved.
BRING IT FASTER
Potential Reasons:
We keep refining work for current sprint
Customer is sending work in small batches due to the nature of work (Internal or External CRs, Customer Complaints, Production defect etc)
Priority related decisions are taken late.
Developers playing safe and taking less work to keep reports Green.
PRODUCT OWNER: Put all your effort to ensure that Product Backlog is not starving. If required information is dependent on customers or other teams, collaborate with them and come up with a working agreement to ensure that we have sufficient items ready.
Keep items in Product Backlog ordered and refined in advance for upcoming 2-3 sprints.
DEVELOPERS: This kind of behaviour can bring challenges related to focus and achieving sprint goal, keep PO and Scrum Master informed about your challenges, highlight in Retrospective.
SCRUM MASTER: Are developers playing safe? Ensure that not delivering 100% forecasted work is not seen as performance issue by management, this will wipe out the culture of experimentation and being transparent.
If it’s a Product Management issue then coach accordingly.
If nothing works and this burndown trend is the result of nature of work (Internal or External CRs, Customer Complaints, Production defect etc) then consider below two points as well:
Discuss sprint length in Retro, may be the sprint length is very long for this kind of work and opting a shorter sprint length might solve this problem. Additionally, can give opportunity to pick the highest value items more frequently and delivering value faster.
If we are not solving a complex problem in a complex environment, in that case It can also be discussed whether we need to use Scrum?
DEVELOPERS’ NIGHTMARE
Potential Reasons:
Work added in Sprint Backlog is more than developers’ capability and increasing.
Someone other than developers, is empowered to decide how much developers will deliver.
Pressure to deliver work by a fixed date, probably release is near.
Nature of work is Complex but Fixed scope - Fixed time (FIX BID) contract was signed - by someone - without consulting Developers
PRODUCT OWNER: There would be serious quality issues like Hard coding, Technical debt etc if developers are not comfortable with the amount of work they are being pushed to deliver. Attrition will go high and in long term quality and capability both issues will come. Empathise with developers. Plan with Stakeholders to ensure long term success.
DEVELOPERS: You are delivering. Ensure that leadership is aware of this situation of overburdening and its potential consequences. Discuss in Retro as a team to explore potential solutions as well.
SCRUM MASTER: This is not something that developers can resolve themselves. This is a Systemic Issue and coming because of the management’s ways of working. As an organizational coach, help managers understand the long-term loss from this behaviour and long-term benefits of empowering developers by considering their opinion while contracting and considering their capacity while planning a sprint.
WE DON’T CARE
Potential Reasons:
A completely new team and developers don’t understand the purpose behind using Burndown Chart so they simply ignore.
Developers understand the purpose but they “don’t care” what’s happening.
Sprint planning was done with zero understanding about work, later they found everything is blocked. – Possibility is very less but if it is, it’s serious
PRODUCT OWNER: You can only help if the reason is zero understanding about work, in that case spend time with team, refine items, resolve their queries related to functionalities. Beware, in this kind of burndown there is no transparency on progress and sprint can end up with surprises.
DEVELOPERS: You can only tell that what is the reason behind this flat line. Go to PO if you need more clarity on work. Go to Scrum Master for help if you don’t know the purpose behind using or how to use burndown.
SCRUM MASTER: If developers don’t understand how to use burndown or its purpose, maybe some guidance and mentoring would be enough.
Bigger problem is they don’t care about the work, it’s tracking and it’s outcome. Start from retrospective but if needed go for 1:1 discussion in psychologically safe environment to identify the root cause behind not caring or not being motivated and based on the insights take right steps as coach.
If Sprint planning was done with zero understanding, then coach PO and Developers to help them understand the importance of refinement and ensure that it’s improving.
SPRINT END, FOLLOW THE PROCESS
Potential Reasons:
Team doesn’t update the progress in tool (Jira, Version1 etc), maybe they consider it as an overhead.
Mini waterfall in sprint, component teams (Dev, QA etc) are doing phase wise development and everything is completed at the end of the sprint.
Items are marked done at the time of Sprint Review with Stakeholders.
PRODUCT OWNER: This kind of burndown can bring surprises for you at the end of the sprint. Though Scrum Master will coach team in this scenario but feel free to bring your perspective in retrospective or anytime during the sprint because throughout the sprint there is no clarity that how far we are from Sprint Goal.
If team is waiting for Sprint Review to mark items done then we need to understand that Review is for Stakeholders to provide feedback on done items. PO can review the item anytime during the sprint and items will be marked done if they fulfil all the Definition of done criteria.
DEVELOPERS: Keep updating the work status in whatever tool you use to manage work. This will provide clarity to everyone on the progress towards Sprint Goal and will help you to have meaningful conversation with PO to adjust the scope of Sprint Backlog if needed in between the sprint. This kind of adaptation is only possible by inspect the reality and to know reality, transparency is must. These are the three pillars of Scrum, how we can be benefitted by Scrum without the pillars which Scrum is standing on.
SCRUM MASTER: Coach team and help them understand the benefits of knowing the progress towards Sprint Goal, creating this awareness will help them to adopt this practice. Probably currently they are maintaining burndown because they are asked to do it on the name of process or compliance but no adoption.
If team is waiting for Sprint Review to mark items done, you can help them as a teacher with Scrum Theory, purpose behind the recommended practices and as a mentor create new experiences by helping them practice what they are learning.
NOTHING BAD IF IT’S NOT A PATTERN
Potential Reasons:
Future is unpredictable, Humans don’t have superpower to plan everything precisely. Ignore if it happens once in 3-4 sprints. It could be because of scope adjustment, unplanned leaves or any other reason.
If it’s a pattern then probably team didn’t yet identify their collective capability as team.
Or the estimation technique (Eg: Story Point) they use, probably better understanding as a team needs to be developed.
(All these are small and easily manageable reasons)
PRODUCT OWNER: Hardly anything Product Owner needs to do in this scenario.
DEVELOPERS: If it’s a pattern then identify the root cause behind that and work on it.
SCRUM MASTER: Nothing serious if not a pattern.
If the 1st burndown (Few items not delivered) is a pattern then ensure that developers are not pushed by someone to take work more than their capability and also ensure that they have good common understanding about the estimation technique they use.
If the 2nd burndown (Finished early) is a pattern then you might want to explore that why Developers take less work when they can deliver more? Coach based on the root cause identified.
FEEL SAFE AND RELAX
Potential Reasons:
Team’s performance is directly linked to team’s velocity or spill overs items etc. so team is ensuring that you get what you want. Maybe they are giving higher story points to items to improve their velocity.
Team’s focus is on creating good Metrics rather satisfied customers.
Team is not motivated to achieve Organizational Goals but their priority is safety and comfort.
PRODUCT OWNER: This is a Systemic issue probably PO cannot do much in this case.
DEVELOPERS: It’s showing “your” behaviour that you are taking less work than your capability but where this behaviour is coming from? You are the best people to think and answer this question. Help Scrum Master to understand the root cause. Your transparency will help Scrum Master to deal with this the underlying causes.
SCRUM MASTER: You might want to explore that why Developers take less work when they can deliver more?
Are they being judged on not completing everything? In this case, definitely they won’t take risk or experiment by challenging themselves. Coach the leaders, it needs a cultural change to fix this behaviour.
Velocity is seen as a metrics for measuring performance? Higher story points can be given to items to increase velocity with less work. Coach the leaders on measuring outcome-based metrics rather output based metrics.
Are they simply not motivated? May be their KPIs are too simple to achieve and do not give them any purpose to push their limits and achieving audacious goals for their growth. In long term it can become an impediment for organization in its growth.
In all these scenarios majorly, you need to coach the leadership and help them adopt the required behaviour to drive the culture to the right direction.
HOLD ON, YOU NEED A PLAN
Potential Reasons:
No Knowledge. It’s 1st sprint, Team (and/or customer) is new to scrum and doesn’t understand the difference between Product backlog and Sprint Backlog.
Anyone (Customer, Other Teams etc.) can add work in Team’s Sprint Backlog directly without Product Owner’s or developers’ consent.
Pressure to deliver work by a fixed date, probably release is near.
Developers need help, they don’t understand the work functionally or technically.
PRODUCT OWNER: Adding work more than the capacity of team is not going to be delivered. If delivered then there would be quality issues, hard coding, production defects and unsatisfied & disappointed customers.
Plan the releases keeping development capacity in mind, be transparent with customers and make agreements accordingly, avoid going for fix bid contracts in complex environment, collaborate with developers before committing anything to customers.
DEVELOPERS: Leverage retrospective to express your pain. If knowledge or understanding is the problem keep PO and Scrum Master informed and discuss the solutions.
SCRUM MASTER: If Scrum knowledge is the problem, then help with knowledge and practices, things will improve in a couple of sprints.
If Functional knowledge is the problem, then ensure that Developers and Po are collaborating to resolve this.
If Functional knowledge is the problem, then ensure the ensure that team is getting whatever help is needed (Internal Learning Session, External trainings, Shadowing, Pair Programming etc.)
If it’s about not respecting the roles and pushing anything to Scrum Backlog by anyone then working agreements can be helpful with the teams within organisation or with customers.
Ensure that Product Owner is skilled enough to manage Product Backlog, understand the consequences of not considering developers’ capacity.
ADAPT TO THRIVE
Potential Reasons:
Team is matured enough and empowered to plan their work considering their capability.
Estimations are précised and very less unknowns in work.
Maybe it’s a “FEEL SAFE AND RELAX” team in the skin of “A MATURE SELF ORGANIZED TEAM”.
PRODUCT OWNER: Hopefully you are getting a clear idea on how we are progressing towards release; your roadmap is clear in your mind with little or no risk and you are able to answer the stakeholders’ questions like: How much time needed or how much money needed confidently.
DEVELOPERS: Keep doing the good work and keep trying to push your limits. That will make you a better professional and will make your organization stronger.
SCRUM MASTER: If this is a “FEEL SAFE AND RELAX” team in the skin of “A MATURE SELF ORGANIZED TEAM” then work with leaders to improve the system as discussed in ‘feel safe and relax’ section.
Else this is the scenario where team might not need you for full time. You can still serve them as need or requested but probably your contribution should be more towards serving the organization to improve the System and Practices.
About me
I am Prateek Nigam, a Business Agility Coach and Accredited Kanban Trainer, have supported teams at companies like Yamaha, Fiserv, BCG, and Lowe’s in improving delivery, reducing bottlenecks, and building flow-driven systems that create measurable outcomes.
Through Agility Wave, I offer coaching and training in Kanban, Scrum, Agile, and leadership development, helping teams implement structured workflows, track their flow, and achieve sustainable productivity.
For more insights, visit https://www.agilitywave.com
For queries, call: +91 – 9667540444 Or email: support@agilitywave.com
Comments