A burndown chart shows the amount of work that has been completed in an epic or sprint, and the total work remaining.
Burndown charts are used to predict your team's likelihood of completing their work in the time available. They're also great for keeping the team aware of any scope creep that occurs.
Burndown charts are useful because they provide insight into how the team works. For example:
If they consistently miss their forecast, this might be a sign that they've committed to too much work.
If the burndown chart shows a sharp drop during the sprint, this might be a sign that work has not been estimated accurately, or broken down properly.
The estimation statistic is the unit of measurement your team will use to estimate work. You can measure work using story points, hours, or you can come up with your own statistic.
Sprint burndown chart
This report shows the amount of work to be done in a sprint. It can be used to track the total work remaining in the sprint, and to project the likelihood of achieving the sprint goal.
- Estimation statistic: The vertical axis represents the estimation statistic that you've selected.
- Remaining values: The red line represents the total amount of work left in the sprint, according to your team's estimates.
- Guideline: The grey line shows an approximation of where your team should be, assuming linear progress. If the red line is below this line, congratulations - your team's on track to completing all their work by the end of the sprint. This isn't foolproof though; it's just another piece of information to use while monitoring team progress
Epic burndown chart
This report shows you how your team is progressing against the work for an epic.
- Epic menu: Select which epic to view data for.
- Work added: The dark blue segment shows the amount of work added to the epic in each sprint. In this example, work is measured in story points.
- Work remaining: The light blue segment shows the amount of work remaining in the epic.
- Work completed: The green segment represents how much work is completed for the epic in each sprint.
- Projected completion: The report projects how many sprints it will take to complete the epic, based on the team's velocity.
Velocity Chart
The Velocity Chart shows the amount of value delivered in each sprint, enabling you to predict the amount of work the team can get done in future sprints. It is useful during your sprint planning meetings, to help you decide how much work you can feasibly commit to.
- Estimation statistic: The y-axis displays the statistic used for estimating stories. In the example above, the team is using story points. Estimates can also be based on business value, hours, issue count, or any numeric field of your choice.
- Commitment: The gray bar for each sprint shows the total estimate of all issues in the sprint when it begins. After the sprint has started, any stories added to the sprint, or any changes made to estimates, will not be included in this total.
- Completed: The green bar in each sprint shows the total completed estimates when the sprint ends. Any scope changes made after the sprint started are included in this total.
- Sprints: The x-axis displays the last 7 sprints completed by the team. This data is used to calculate velocity.
Velocity is calculated by taking the average of the total completed estimates over the last several sprints. So in the chart above, the team's velocity is (17.5 + 13.5 + 38.5 + 18 + 33 + 28) / 6 = 24.75 (we've ignored the zero story point sprint). This means that the team can be expected to complete around 24.75 story points worth of work in the next sprint.
Cumulative Flow Chart
A Cumulative Flow Diagram (CFD) is an area chart that shows the various statuses of work items for a product, version, or sprint. The horizontal x-axis in a CFD indicates time, and the vertical y-axis indicates cards (issues). Each coloured area of the chart equates to a workflow status (i.e. a column on your board).
Work in Process or Work in Progress (WIP)
Tracking work items that are started, but not yet finished, can help you improve the overall flow of value through the system.
Practically speaking, work cannot add value to the customer, team, or organization unless it’s finished work
Lead Time and Cycle Time
Lead time and cycle time are two useful metrics for understanding how long work takes to flow through your Kanban system.
While cycle time tracks the amount of time we spend working on it while it's on our board.
Throughput
Throughput is the average number of units processed per time unit.
In a Kanban system, examples can include “cards per day,” “cards per week,” or “story points per iteration.”
Kaizen is a Japanese word that literally translates to change for the better.
It's a fundamental part of lean methodology.
Improvement Cada
If you're a leader in your organization, you should allow individuals on your team to suggest issues or identify waste as and when they see it. - That's right.
An organization cannot self-improve unless the people who are part of it are comfortable talking about inefficiencies and waste.
Gemba, the real place where our work is done. It could be chat, our ticket tracker, or search control system.
Not being in touch with the gemba make you unable to make good decisions as a leader.
A Lean adoption requires changing mindsets. Pulling instead of pushing and delivering the minimum, and then iterating based on feedback are very different for how many organizations work on both explicit and implicit levels. In terms of specific DevOps practices, it's continuous delivery. To adopt Agile, and Lean, and DevOps it requires people to learn new skills.That takes some work, but it's not the hard part. It's changing the culture and way of working that's hardest.
The empowerment and respect for employees that a real Lean and Agile implementation brings, is a major game changer, not just to business outcomes but to the quality of life of the teams involved.
Not being in touch with the gemba make you unable to make good decisions as a leader.
A Lean adoption requires changing mindsets. Pulling instead of pushing and delivering the minimum, and then iterating based on feedback are very different for how many organizations work on both explicit and implicit levels. In terms of specific DevOps practices, it's continuous delivery. To adopt Agile, and Lean, and DevOps it requires people to learn new skills.That takes some work, but it's not the hard part. It's changing the culture and way of working that's hardest.
The empowerment and respect for employees that a real Lean and Agile implementation brings, is a major game changer, not just to business outcomes but to the quality of life of the teams involved.
No comments:
Post a Comment