How to Use Burndown Charts for Agile Product Development
If one thing is certain in product development (or in life), it’s that time is always passing, and there are always tasks to be completed. There’s no more straightforward way to calculate both of these critical metrics than a simple burndown chart.
Burndown charts help agile teams visualize time vs. task completion, which means the amount of work left compared to the amount of time planned in the development of a product or a specific sprint.
In this post, we’ll explain what burndown charts are, the benefits of using them, and how they are used by development teams. We’ll also explain the difference between burndown vs. burnup charts, product burndown charts vs. sprint burndown charts, and share helpful tools for integrating critical metrics in Jira. Now let’s slide down that y-axis!
What is a burndown chart?
A burndown chart is a visualization of how much work is left to do and how much time there is to complete it. Visible to everyone, this graphical representation predicts how much work the team plans to complete within the allotted time. Burndown charts are also used to measure how quickly an agile team is moving through and completing customer user stories. They are excellent for keeping the team aware of any scope creep.
Let’s look at what each part of the graph represents. The amount of work remaining is shown on the vertical axis. The time that has passed since starting the project or sprint is displayed on the horizontal axis. So, the x-axis is the timeline of the project or iteration, and the y-axis is the work that needs to be completed.
The total amount of work to be done on the project is at the top of the y-axis on the left, and the endpoint on the far right of the x-axis represents the final day of the project or specific iteration. The start and endpoints are connected by the ideal work line, a straight line that shows what the team hopes to accomplish within a predetermined time frame. Another line, the actual work line, shows the amount of work that remains and how quickly the team is actually performing.
Actual work line vs. ideal work line
A burndown chart shows both the actual work line and the ideal work line. Both lines begin at the start point at the top of the y-axis. As the project or iteration goes on, the actual work line will oscillate around the ideal work line, depending on how the team is progressing.
If the team stays on schedule, the actual work line won’t deviate much from the ideal work line and remain decently straight. If the team hits a lot of time-sucking roadblocks during the project or sprint, the actual work line will be more of a wild squiggle, and it may not reach the x-axis endpoint before time is up.
The benefits of using burndown charts
Burndown charts are helpful in a few key ways. These charts:
- Provide a visual representation of the progression of work completed over time.
- Keep product owners informed of development progress for a product or specific sprint.
- Keep the whole development team on the same page about how far along a product is.
- Are regularly updated as work is completed and as time passes to show product progress in real-time.
- Provide advance notice if a product is not progressing fast enough.
- Capture clear metrics that can be reviewed during retrospectives.
Burndown chart vs. burnup chart
A burndown chart tracks how much work remains by starting at the tip of the y-axis and tracking downward toward where the endpoint meets the x-axis as time goes on and work is completed.
A burnup chart does the opposite. The start point is at the bottom corner of the graph to the left most of the x-axis. A burnup chart’s ideal work line and actual work line track upward as work is completed and time passes. Toward the top of the y-axis is another horizontal line representing the scope of the project, such as the number of story points needed to complete. If the scope becomes larger, say if story points or sprint backlog items are added, the scope line rises to account for the elevated goal.
If the scope of a sprint or project changes due to unexpected developments or stakeholder insight, which is bound to happen over the course of development, these changes are represented by the scope line. This can make burnup charts a slightly more adaptable tool.
Both burndown and burnup charts track a team’s velocity, workflow, and progress. A burnup chart’s scope line takes into account the evolving nature of software development and how the goalposts can move over the course of a project, which makes them ideal for tracking a project as a whole. While they are both effective tools, a burndown chart could be better utilized during a sprint because the number of tasks in a sprint is less likely to change.
Product burndown vs. sprint burndown chart
There are two different kinds of burndown charts. A product burndown chart shows how much work remains for the entire project, whereas a sprint burndown chart shows how much work remains in a specific iteration.
A product burndown chart collects a larger amount of data. It represents everything that needs to be completed on a product during the specific time requirement agreed upon at the beginning of the project.
A sprint burndown chart helps Scrum masters visualize how fast the agile team gets the work done and how much work is left to do during a sprint. It shows the Scrum team’s progress by displaying how much work actually remains instead of time spent. Over the course of a sprint, the chart will slope downward across the completed story points.
If the burndown line on a sprint burndown chart is not tracking downwards by the time you reach the middle of the sprint, it’s a sign that the sprint is not going well, and it’s up to the Scrum master to get the team back on track.
Working on your next product plan? Learn about common agile planning mistakes and how your team can avoid these common pitfalls.
Burndown charts in Jira
Broken Build’s Agile Reports and Gadgets include burndown and burnup charts for both Scrum and Kanban.
The application is designed for Jira, so you can integrate reporting in real-time. Having access to immediate metrics helps teams spot bottlenecks and dependencies, so they can be addressed sooner rather than later. The application lets you export charts and customizable reports to share with team members and stakeholders or to review during retrospectives.
How Easy Agile can help your team
We’re passionate about helping agile teams work more efficiently and effectively while always putting the needs of the customer first. We create products specifically designed for Jira users, including Easy Agile TeamRhythm, Programs, Personas, and Roadmaps.
Try Easy Agile TeamRhythm to build simple and collaborative story maps in Jira. Our tool will help you transform your product backlogs into an impactful visual representation of the customer journey. It’s the highest-rated story mapping app for Jira, trusted by over 120,000 users at companies like Amazon, Twitter, Starbucks, Rolex, and Adobe.
Related Articles
WorkflowUsing a Sprint Burndown Chart to Keep Your Product on Track
Keeping stakeholders in the loop is one of the key responsibilities of a product owner. A ton of work goes on behind the scenes before stakeholders can be presented with information about a product's deliverables and timeline. If sprints are your framework for getting work done and projecting delivery dates, the agile development team needs a way to make sure it's working through the product backlog at the right pace. The sprint burndown chart can show you the way.
In this post, we’ll talk about how to use a sprint burndown chart to monitor if your team is on track to complete its work and how putting user stories into sprints and epics generates even greater insights via user story maps.
What is a sprint burndown chart?
Image credit: Atlassian
First, a review: A sprint is a fixed period of time — typically between two and four weeks — that an agile software development team uses to complete a defined set of work.
A sprint burndown chart is a visual comparison of how much work has been completed during a sprint and the total amount of work remaining. It helps measure a Scrum team's progress, and it provides an easy view of whether the team needs to make any adjustments to complete its work for the current sprint iteration.
A burndown chart is a graph with a y-axis and x-axis 📉. The vertical axis measures the total amount of work that the team estimates it will complete during its current sprint. The horizontal axis shows the number of days remaining until the end of the sprint. On the chart are two lines: the actual work line (a line that represents the team's progress) and the ideal work line (a straight line from the top of the y-axis to the end of the x-axis).
You want your actual work line to follow your ideal work line as closely as possible. This would mean that work is being completed incrementally and at such a rate that it can be completed by the end of the sprint. Sprint goal achieved. 👍
A good practice for a team's product owner is to review the burndown chart on a daily basis. Doing so will allow you to detect if there are any progress issues happening in the sprint. For example, if your actual work line is trending above the ideal work line, then too much work remains to be completed by the end of the sprint at the current pace. We'll break down a few reasons why this may be happening later in the post. 😉
The sprint burndown chart is also a great tool to use during a sprint retrospective. Looking at this as a team can help generate talking points to discuss around the sprint retrospective's three key questions: What went well in the sprint? What didn't go as well as we hoped? How can we get better in the next sprint?
A primer on estimation methods
To measure effort on the vertical axis, we need to choose a metric.
Historically, traditional software teams used time to estimate the effort needed to complete a task or a project. For example, "I think it will take me three days to finish that user story." However, this approach can be risky because people tend to underestimate the amount of time it will take to finish a project.
The unit of measure on your sprint burndown chart's y-axis will depend on your estimation metric of choice. Let's review two common ones employed by agile sprint teams.
Ideal days
An ideal day is an estimate by a software developer of how many uninterrupted days it will take to complete a task. Assuming an ideal workday is eight hours of interruption-free work, the estimate could be stated as, "That user story will take me two ideal days." A benefit of this approach is that it accounts for work disruptions; however, it can be problematic because it often positions estimates as best-case scenarios.
Story points
Agile teams use story points as a relative estimate of effort as opposed to a time-based approach. Instead of saying, "I think this task will take me two days to finish," you would state, "I think this task is worth two story points." In this estimation technique, two story points are twice the effort than one story point.
Teams can use ideal days as a baseline to calibrate their story point estimates. For example, one ideal day can be equivalent to one story point, two ideal days to two story points, and so on.
A main benefit of using story points to estimate is that it allows teams to focus on relative measures of effort instead of thinking about how long it will take to finish a task.
Why your sprint burndown might be off track
A perfect actual burndown line is like Bigfoot — if it's been witnessed, it's probably a hoax. 😂
No team can perfectly estimate its work and develop at the exact pace represented by the ideal line. That said, if you notice large differences between your actual line and the ideal line (i.e., your actual line is much higher or lower than the ideal line), a number of things might be occurring:
- The team over- or under-committed to the amount of work at sprint planning
- Story points were added to or removed from the sprint after it started (scope creep)
- The estimated effort for some user stories is off
As a product owner, when you notice something that's off about your line after your daily review of your chart, you should mention that to your team members. The daily stand up is a perfect time to do so.
User stories and epics provide the big picture
User stories describe how a functional part of a product will work from a user's perspective. The common format of a user story reads, “As a [user role], I want to [user activity] so that I can [user goal].” For example, one might read, “As a new customer, I want to sign up for this product so that I can create my profile.”
User stories are placed in sprints to show what work (from the user's perspective) will be finished and by when. They can also be placed in epics to group them into themes within a product. Epics are widely used by agile teams to represent the high-level activity users will accomplish while using a product.
In our example above, an epic can capture all of the user stories that center around user signup, such as signing up, adding payment information, creating a user profile, and configuring notification settings.
If the sprint burndown indicates that the team is off track for a given sprint, then a combined view of sprints and epics can help you determine what impact that might have in the big picture. And, as we’ll see next, an interactive user story map can fix the problem.
User story maps: A view of epics and sprints
A sprint burndown chart is one of the handiest tools an agile software development team can use to make sure they're working and delivering at a solid pace. The burndown chart shows if any adjustments need to be made to your sprint.
User story maps provide another level of insights into team progress by:
- Showing sprints as vertical swimlanes
- Displaying epics as columns that represent the user journey through the product
This combination of swimlanes and columns unflattens your sprint backlog. It visualizes what the team will deliver and by when.
With Easy Agile User Story Maps for Jira, you can supercharge your ability to make adjustments to your sprint. It can help you:
- Create new user stories
- Edit story points on a user story
- Assign items in the backlog to an epic and a sprint
With this tool, teams can view their sprint statistics at a glance and take action. They can ensure they don't overcommit and that they're on track to achieving their sprint goals. It’s the most comprehensive user story map solution in the Jira marketplace for taking action to adjust your sprints from a big-picture viewpoint.
WorkflowSprint Backlog 101: Never Stop Refining
A sprint backlog is like an agile team's treasure map — checking off each item is like visiting a different place on the map. By the end of a sprint or iteration, the team will have delivered previously agreed outcomes and ultimately achieved their sprint goal. This is like getting to the ✖️ on a treasure map.
Join us as we find the answers you need to successfully complete each sprint. You'll learn about a sprint backlog’s purpose, plus who creates, owns, updates, and uses it.
What's a sprint backlog?
A sprint backlog consists of the items that need to be completed in order to get to the sprint goal. It should go into artifact during the sprint planning meeting. A sprint backlog has three parts:
- The sprint. Each sprint backlog targets a specific iteration.
- The sprint goal. This is the higher level aim for each sprint. To achieve it, the development team completes certain items from the product backlog.
- A plan. The sprint backlog represents a plan to deliver a product increment by the end of the sprint. It's organized to allow for progress tracking with to-do, in-progress, and done items, plus effort estimations and remaining workload.
The sprint backlog should always be accessible and up-to-date so that the development team understands the work and can see what is coming up next. It should also have enough detail to allow tracking work progress.
Each sprint starts with a sprint backlog, and the artifact's lifespan equals the sprint's duration. You may expect to find work items — user stories, tasks, or bugs — in it.
The sprint backlog is the development team's go-to home to find all the ideas for what to work on. At every Daily Stand-Up,, the team looks at it to let others know what they did the day before. Additionally, they recall or adjust priorities based on what they need to do for the next day(s).
🧐 During the Daily Stand-Up, developers also use the sprint backlog to evaluate the sprint's progress.
The sprint backlog is not only a way of keeping the development team's eyes on the prize. 👀 It's also a way to discuss how well they achieved the sprint goal.
At any point in a sprint, to-do, in-progress, and done items are included in the sprint backlog for anyone to review and use to calculate the remaining workload. This helps verify if the development team is on track to achieve the sprint goal. ✌️
Jira provides a burndown chart to check the development team's work. This displays the remaining workload for the current sprint. In addition, the chart shows:
- Work in progress
- The distribution of work throughout the iteration
A Jira burndown chart also helps evaluate whether additional items fit into the sprint and effort estimations were accurate.
🛑 Keep in mind that you don't need a sprint backlog if you follow the Kanban framework. That’s because Kanban isn’t about working in timeboxes (the sprints).
Now, the sprint backlog isn't an off-the-shelf artifact that you can use in your project — every project is unique. So, someone must be responsible for populating the sprint backlog with work items.
Besides defining what a sprint backlog is, we should discuss what sets them apart from product backlogs.
Sprint backlogs vs. product backlogs
Though their names are similar, a sprint backlog and product backlog serve different purposes. A product backlog is:
- A collection of work items to either bring a new product to the market or improve an existing product
- A list of work items to tackle in the future
- A set of work items arranged by priority, with the most priority at the top
- The source of the sprint backlog items
On the other hand, a sprint backlog is:
- A subset of work items from the product backlog
- A group of items to work on during the next sprint
Here’s how the two backlogs meet: The product backlog provides work items for a sprint backlog. And, by the end of a sprint, the team might transfer incomplete work to the next sprint or the product backlog. If the work items have high priority, they should go into the next sprint. If not, they should go into the product backlog for a later sprint.
Essentially, a product backlog covers a greater amount of time than a sprint backlog. However, like the sprint backlog, the product backlog might evolve to reflect changes in the market or customer needs and, the development team needs both in order to deliver product changes.
Now, the sprint backlog isn't an off-the-shelf artifact that you can use in your project — every project is unique. So, someone must be responsible for populating the sprint backlog with work items.
Who owns and creates sprint backlogs?
Here are the team members involved in creating sprint backlogs:
- The Scrum Master. During the Sprint Planning ceremony, the Scrum Master uses the product backlog to create the sprint backlog — the output. However, the Scrum Master doesn't do it alone.
- The development team. When moving product backlog items to the sprint backlog, the Scrum Master considers the development team's input. ⚖️
- The Product Owner. The Scrum Master needs the Product Owner's agreement to include product backlog items in the sprint backlog. 👌 And if the development team has questions about the product backlog, the Product Owner is the one to ask.
The sprint backlog's creation is one part of the agile workflow that shows how essential teamwork is to agile. Nevertheless, the sprint backlog must always be owned by someone throughout the workflow. Otherwise, these artifacts can get lost and become outdated.
Scrum methodology says that the whole agile team owns the Sprint Backlog. And by "agile team," we mean the Scrum Master, the Product Owner, and the development team.
That’s because all agile team members contribute:
- The Product Owner knows what the development team should deliver by the end of the sprint. Plus, they order product backlog items by priority. In other words, the Product Owner constrains the product backlog items that should go into the next sprint backlog.
- The Scrum Master has enough experience to distribute the development team's work throughout the sprint. When considering sprint backlog item dependencies, that distribution makes the most sense.
- The development team knows how long similar Sprint Backlog items take to complete. ⏲️ This means they can determine the sprint goal's feasibility within a certain time frame.
Remember, the sprint backlog is a living document, so team members should update it as needed. Let’s look at how a sprint backlog can change.
Updating the sprint backlog
The sprint backlog should adapt to answer market trends and customer needs as they arise. Those changes might influence items in the product backlog and how they’re prioritized. As a result, the sprint backlog changes.
Let's have a look at what may cause a sprint backlog to change and who makes the updates:
- Effort estimations were not accurate enough. If the development team realizes that some work items will take longer than expected, they should raise a 🚩. They should then negotiate the scope of the sprint backlog with the Product Owner without compromising the sprint goal.
- A new, higher-priority user story, task, or bug comes up. If that happens, the development team should add it to the sprint backlog. That might impact the sprint's duration or push some items to the next sprint.
- Progress in completing a user story or a task or solving a bug changes daily. As this happens, the development team should keep updating the remaining workload they estimated for the current sprint. And they should do it during the Daily Stand-Up or Daily Scrum meeting. Once the development team finishes all the work in the sprint backlog, they achieve the sprint goal. This means the development team implemented the product increment, which is ready for delivery. 📦
- A sprint backlog item is no longer needed. This might be due to a shift in the market or customer needs. If that happens, the development team should remove the item from the artifact. 🗑️
- The development team better understands sprint backlog requirements as the sprint continues. So, they might realize that to achieve the sprint goal, they need to include more items in the sprint backlog.
The sprint backlog: A guide for sprint success
A sprint backlog is a guide for completing a sprint goal. This means that its lifecycle is short and equals the iteration's duration. It's a visual representation of the sprint that supports Scrum team discussions on in-progress and to-do work.
This backlog may also be the most reassuring Scrum artifact for developers, as it assures them the work is organized and no additional work items will fall from the sky without their knowledge. If the workload must increase, the team will debate it and weigh the developers' experience-based opinion.
With a sprint backlog, the team perfects its ability to plan sprints, estimate effort, and allocate resources. They learn how long work takes and how much of it fits into a sprint. And by learning this, the team learns the resources they need to get to the finish line.
Easy Agile TeamRhythm is collaborative sprint planning tool that helps your team with the shared context that the story map format provides. TeamRhythm helps your team to:
- Visualize a meaningful picture of work on the user story map, sequenced into sprint swimlanes
- Create, estimate and prioritize user stories right on the story map
- See comitment at a glance with sprint statistics and sprint goals displayed on each swimlane
Try planning your sprints with Easy Agile TeamRhythm. We’re confident it will help your team collaborate even more seamlessly.
Agile Best Practice9 Tips to Help You Ace Your Sprint Planning Meetings
The sprint planning meeting helps agile teams plan and get on the same page about each sprint. It’s an opportunity to decide on prioritization based on the product vision, issue urgency, stakeholder feedback, and knowledge from the previous sprint.
The goal of the meeting is to determine which backlog items should be tackled during the upcoming sprint. The team, guided by the product owner and Scrum Master, decide which items from the product backlog should be moved to the sprint backlog for hopeful completion over the coming weeks (sprint duration).
Sprint planning plays a critical role in the Scrum process. The meeting ensures teams enter a sprint prepared, with work items chosen carefully. The end result should be a shared understanding of sprint goals that will guide the next sprint.
While sprint planning should occur before any type of sprint, for the purposes of this article, we will focus on sprint planning sessions for Scrum teams. Continue reading to learn our top tips for a successful sprint planning meeting. 🎉
How does the sprint planning meeting fit into the Scrum framework?
Scrum is a hugely popular agile methodology used in product development. The process involves a series of sprints that are improved upon and adjusted based on continual feedback from customers, stakeholders, and team members.
The sprint planning meeting sees the entire team comes together to decide what work they hope to complete over the upcoming sprint. The product owner helps decide which priority product backlog items move to the sprint backlog. This is an incredibly important phase that guides the team’s goals over the next two weeks.
The Scrum Master acts as a Scrum guide. They help the development team stay on track in each sprint, ensuring everyone gets the most out of the process. The Scrum team works together to complete the amount of work decided on during sprint planning. To ensure everyone remains on track and on the same page, daily stand-ups are held each day. This provides an opportunity for team members to address any issues or potential bottlenecks that could keep work from running smoothly.
Following the sprint, a sprint review takes place, which gives stakeholders an opportunity to provide feedback. Finally, a sprint retrospective meeting gives the team an opportunity to assess and improve upon their process. The Scrum concludes and begins again with another sprint planning meeting.
Here are some tips to make sure each sprint planning meeting sets you up for success:
1. Reserve the same time for sprint planning ⏰
Book your sprint planning meeting on the same day and at the same time every two weeks to ensure your entire team keeps that time slot available. Sprint planning is vital to the success of each sprint — it’s a meeting that shouldn’t be shuffled around.
Pick a time that works for everyone involved, asking for feedback from your team about when is best. Schedule the meetings well in advance in everyone's calendar so that no one forgets about it or books other engagements.
2. Set a sprint planning meeting duration and stick to it ⏳
Sprint planning is important, but that doesn’t mean it should take forever. Set a time limit for your meeting, and do your best to stick to it. If you are well prepared with an agenda and refined backlog, you should be able to get straight to planning.
We recommend scheduling no more than 2-4 hours for sprint planning. Let the Scrum Master be in charge of ensuring the team stays on track and completes planning in the allotted time.
3. Complete backlog refinement before sprint planning begins 📝
Complete your backlog refinement ahead of your sprint planning meeting. Otherwise, you will spend far too much time adding details, estimating, or splitting work.
The sprint planning meeting should be reserved for planning and goal setting. While the backlog shouldn’t be set in stone, it should provide team members with enough details to move forward with planning instead of refinement.
4. Incorporate stakeholder feedback from the sprint review 😍
What insights did stakeholders share throughout the sprint or during the sprint review? You are designing this product for them, so incorporating their feedback is crucial to the end result.
Make sure every decision is based on customer needs. After each sprint, share your product goals and sprint goals with your stakeholders and adjust per their feedback.
5. Incorporate sprint retrospective insights 💡
Sprint retrospectives are a critical part of the agile process, providing a time for the team to discuss how they can improve. There are lessons to be learned every time you complete a sprint or iteration. Agile continually takes what a team learns and turns those experiences into actionable improvements. So, ignoring these lessons would be very un-agile of you. 🤔
How did the last sprint go? Was each team member satisfied with the process, and what was accomplished? What changes did your team decide would make the next sprint more effective? Use these insights to make each sprint better than the last one.
6. Clearly define what success looks like ✅
Set clearly defined goals, objectives, and metrics. What is the definition of done? How will the team know if they are successful? You should leave the sprint planning meeting with a clear idea of what needs to get done and what success looks like.
7. Use estimates to make decisions based on team capacity 📈
Overloading your team or any individual beyond their capacity does far more harm than good. The team will be more likely to make mistakes, and morale will diminish as goals remain consistently out of reach.
Use agile estimation techniques and story points to better understand workload and capacity. How much work and effort is needed to accomplish your goals? Ensure you set realistic and reasonable goals based on your best estimations.
8. Align sprint goals with overall product goals 🎉
Ensure you have a goal for the sprint and that all backlog items relate to the end goal. Your sprint goals should work alongside your overall product goals.
Failing to prioritize your objectives can result in a random selection of to-dos. Completing disconnected backlog items will still get work done, but it will result in unexpected outcomes and a low sense of accomplishment for the team. Each backlog item should be chosen with a clear purpose that relates to your product and sprint goals.
9. Leave room for flexibility 💫
Any agile methodology is flexible by nature, and Scrum is no exception. If there isn’t room for flexibility, something has gone seriously wrong.
It's important to acknowledge that not everything will always go to plan. You will continually find new information, stakeholder insights, and dependencies that the team will need to adjust to along the way. Ensure the team understands they need to be flexible and that they are supported throughout each sprint.
Sprint planning made easy
The effectiveness of sprint planning can make or break the coming week for a Scrum team. It’s important for the development team to take the necessary time to prepare for each upcoming sprint. This means going into the meeting with clear goals, objectives, stakeholder feedback, and a refined backlog.
Make the most of your sprint planning and do it with ease using Easy Agile TeamRhythm. Transform your flat product maps into dynamic, flexible, and visual representations of the customer journey. Story points will help your team make decisions and account for capacity while keeping the customer top-of-mind.
Learn more about the benefits of user story mapping and read our ultimate guide to user story maps.