Search Results for 'burn up'


Audio Version:  SPaMCAST 133

Definition:

A burn-up chart is a graph that tracks progress by accumulating a measure of functionality as it is completed over time. The measure of functionality can be compared to a goal, such as a budget or release plan, to provide the team and others with feedback on progress. Graphically the X axis is time and the Y axis is accumulated functionality completed over that period of time. The burn-up chart, like its cousin the burn-down chart, provides a simple yet powerful tool to provide visibility into the sprint or program.

The burn-up chart can be thought of as the mirror image of the burn-down chart, but it is generally extended over multiple sprints to show progress as the project builds toward release and product delivery.

Formula

As with its close cousin, the burn-down chart, there is not really a formula for a burn-up chart as much as there are instructions on how to graphically represent progress against a goal. In its simplest form, the X axis represents time (days, sprints, or releases) and the Y axis represents the accumulated functionality completed over that period of time (stories, value or cost).

Using the basic form of the graph as a base, other data can be integrated. The release plan, which typically includes an outline of the funcitonaity (in story points or function points) for a number, can be overlaid on the chart to give visibility into the anticipated flow of the project. The project budget can be added to the chart to provide feedback on budget utilization; the budget line can be raised or lowered to show how much work remains as changes to scope are incorporated. Value can be tracked on a second Y axis to show the team the relationship between work and value. The burn-up chart is one chart covering the big three topics of on-time, on-budget and on-schedule.

Uses

The burn-up and burn-down charts have many similar uses such as planning and monitoring. Rather than repeat the discussion already published in the Metrics Minute: Burn-Down Charts, I will focus on the major distinctions between the charts. The unique power of the burn-up chart can be found in its ability to provide a holistic view for the project. The view is holistic because the chart can be used to show progress over sprints and releases. To use a photographic analogy, the burn-up chart provides a panoramic view rather than a normal picture, which is narrow slice of real life.

James Shore suggests developing a risk-adjusted burn-up chart to make and meet commitments.  It tracks commitments alongside progress. Adding a continually refined risk-adjustment to the burn-up chart accounts for Steve McConnell’s cone of uncertainty (the cone of uncertainty theorizes that plans are less accurate the farther in the future they are projected). Actual performance (delivered functionality) can be tracked against commitments; significant gaps would signal a need to adjust the release plan if performance strays to far from what is possible as established by the cone of uncertainty.

Issues

One issue is that a burn-up chart provides visibility at a high level, rather than progress at a story level. This causes some people concern. Burn-up, like burn-down charts, are not designed as a precise report on where each story is on a day-to-day basis, but rather as a view of how functionality or value has been delivered. The burn-down chart and the detail found in a card wall (or proxy) are better tools to drive a project on a day-to-day basis.

The second issue occurs because value is recognized only when a piece of work is complete.  In software projects, this equates to functional code that has been integrated and tested.  Value is not recognized until work in process is complete.   Alistair Cockburn suggests recognizing functionality when ‘done’ yields more reliable information about the projects actual state than the classic plan based mode. The problem is that if the increment of work is too large the graph will resemble a J with the majority of value accumulating late in the sprint leaving room from negative surprises. The way to avoid this issue is to increase the granularity of the units of work (break the work down in smaller pieces). This will allow the team to recognize value more quickly, and therefore smooth out the curve.

The third issue is also related to the choice of unit of measure for use on the vertical axis. The unit needs to be predictable early in the process. Most physical measures, such as lines of code, can’t be known until you’re very near the end of the sprint or projects. Leveraging a metric that can expand even though scope has not changed muddles the information provided by the chart, thus reducing its usefulness. This issue can be avoided by choosing unit of measure that can’t expand unless additional work is accepted into the sprint or project.  Functional measures, such as Quick and Early Function Points, that translate stories or requirements into numbers are a disciplined/formal mechanism for addressing the unit of measure issue without adding overhead.

Related or Variant Measures

  • Functional Size
  • Velocity
  • Burn-down Charts
  • Earned Value
  • Productivity
  • Cumulative Flow Diagrams

Criticisms

The most significant criticism of the burn-up chart is that, in its basic form, it does not reflect the flow of work.  Work in some sprints does not lead to completed functionality, therefore value is not accrued. This leads to a feeling that partial credit should be given, splitting stories using waterfall stages or other bad practices all in a rush to show progress.  One solution is to use flow metrics by using techniques like Kanban and cumulative flow diagrams is a way of accruing value on a more granular basis if the organization can’t find a measure to split user stories so they can be completed properly in a single sprint.

The final criticism is that burn-up charts do not predict surprises.  This is a false criticism as a surprise by definition is not predictable.  Use the value at risk metric as a risk management tool to help avoid surprises, but vigilance should never be supplanted by measurement.

 

Audio Version:  SPaMCAST 133

Definition:

A burn-up chart is a graph that tracks progress over time by accumulating functionality as it is completed. The accumulated functionality can be compared to a goal, such as a budget or release plan, to provide the team and others with feedback. Graphically the X axis is time and the Y axis is accumulated functionality completed over that period of time. The burn-up chart, like its cousin the burn-down chart, provides a simple yet powerful tool to provide visibility into the sprint or program.

The burn-up chart can be thought of as the mirror image of the burn-down chart, but it is generally extended over multiple sprints to show the strategy being followed as the project builds toward release and product delivery.

Formula

As with its close cousin, the burn-down chart, there is not really a formula for a burn-up chart as much as there are instructions on how to graphically represent progress against a goal. In its simplest form, the X axis represents time (days, sprints, or releases) and the Y axis represents the accumulated functionality completed over that period of time (stories, value or cost).

Using the basic form of the graph as a base, other data can be integrated. The plan data for multiple sprints and the release schedule can be overlaid on the chart to give visibility into the anticipated flow of the project.  The project budget can be added to the chart to provide feedback on budget utilization; the budget line can be raised or lowered to show how much work remains as changes to scope are incorporated. Value can be tracked on a second Y axis to show the team the relationship between work and value. The burn-up chart is one chart covering the big three topics of on-time, on-budget and on-schedule.

Uses

The burn-up and burn-down charts have many similar uses such as planning and monitoring. Rather than repeat the discussion already published in the Metrics Minute: Burn-Down Charts, I will focus on the major distinctions between the charts. The unique power of the burn-up chart can be found in its ability to provide a holistic view for the project. The view is holistic because the chart can be used to show progress over sprints and releases. To use a photographic analogy, the burn-up chart provides a panoramic view rather than a normal picture, which is narrow slice of real life.

James Shore suggests developing a risk-adjusted burn-up chart to make and meet commitments.  It tracks commitments alongside progress. Adding a continually refined risk-adjustment to the burn-up chart accounts for Steve McConnell’s cone of uncertainty.

Issues

One issue is that a burn-up chart provides visibility at a high level, rather than progress at a story level. This causes some people concern. Burn-up, like burn-down charts, are not designed as a precise report on where each story is on a day-to-day basis, but rather as a view of how functionality or value has been delivered. The burn-down chart and the detail found in a card wall (or proxy) are better tools to drive a project on a day-to-day basis.

The second issue occurs because value is recognized when a piece of work is complete.  In software projects this equates to functional code that has been integrated and tested.  Value is not recognized until work in process is complete.   Alistair Cockburn suggests this strategy yields more reliable information about the projects actual state than the classic plan based mode. The problem is that if the increment of work is too large the graph will resemble a J with the majority of value accumulating late in the sprint leaving room from negative surprises. The way to avoid this issue is to increase the granularity of the units of work.  This will allow the team to recognize value more quickly, and therefore smooth out the curve.

The third issue is also related to the choice of unit of measure for use on the vertical axis. The unit needs to be predictable early in the process. Most physical measures, such as lines of code, can’t be known until you’re very near the end of the sprint or projects. Leveraging a metric that can expand even though scope has not changed muddles the information provided by the chart, thus reducing its usefulness. This issue can be avoided by choosing unit of measure that can’t expand unless additional work is accepted into the sprint or project.  Functional measures, such as Quick and Early Function Points, that translate stories or requirements into numbers are a disciplined mechanism for addressing the unit of measure issue without adding overhead.

Related or Variant Measures

  • Functional Size
  • Velocity
  • Burn-down Charts
  • Earned Value
  • Productivity
  • Cumulative Flow Diagrams

Criticisms

The most significant criticism of the burn-up chart is that, in its basic form, it does not reflect the flow of work.  Work in some sprints does not lead to completed functionality, therefore value is not accrued.  Integrating work flow by using techniques like Kanban and cumulative flow diagrams is a way of accruing value on a more granular basis if small complete packages can’t be used.

The final criticism is that burn-up charts do not predict surprises.  This is a false criticism as a surprise by definition is not predictable.  Use the value at risk metric as a risk management tool to help avoid surprises, but vigilance should never be supplanted by measurement.

 

Sometimes you just have to . . .

A friend and colleague recently presented me with a scenario and then as the punchline asked for more ammunition to alleviate the problem.  

The Scenario: (more…)

Getting older and getting wiser!

Getting older and getting wiser!

At the end of the year I take time for reflection, introspection, and retooling; an activity that I highly recommend. The question I often ask myself as I reflect is how can I become more effective and efficient.  For the sake of clarity, I define effectiveness as the ability to deliver desired results.  Effectiveness means that we have to know what we are trying to deliver and that what we are delivering matches the need when it’s delivered. Being “effective” is more complicated than just doing what you were asked to do because that might not be what is needed when you get the end of a piece of work.  Being effective requires efficient execution and carefully listening to feedback.  Efficiency is a far simpler topic.  Efficiency is doing useful work with least amount of energy.  For knowledge workers, the most significant input into the efficiency is their time. A few evenings ago as my wife and I talked over a glass of wine, cider and a few tacos (it was taco night) about plans for the new year, she chided me on wanting to write more columns and extend the podcast franchise.  As Kevin Kruse (SPaMCAST 398) says there are only 1,440 minutes in a day and without a time machine it is nearly impossible to generate more.  Efficient and effective use of our minutes is more than an academic question, it is a matter directly tied to meeting our goals and feeling fulfilled. Over the years I have found nine improvement areas that commonly can be capitalized on at a personal level.  I will openly admit that each item on our list are areas that I strive to be better at almost on a daily basis. (more…)

Metrics Minute:  Burn Down Charts
Thomas M. Cagley Jr.

Audio Version

Definition:

Burn Down Charts are a graphical representation of the work left to be done and of the progress that has been made. The chart is typically drawn to show progress against predictions. The analogy of a glide path has been used to paint a picture of the slope and the ultimate destination of a burn down chart which targeted at completion. One of the most powerful attractions of the burn down chart is that it involves psychology by emotionally tying the metric to completion through the visual representation of a path counting down to zero. 

Formula

There is not really a formula for a burn down chart as much as there are instructions on how to represent progress against a goal graphically. Burn down charts are represented as a standard x/y chart. The x-axis is used as a representation of time. Typically days are used although I have seen charts that span multiple sprints so denominators such as months, milestones or sprints are occasionally used. The y-axis is denominated in units of work (for example story points or hours of effort). The line that connects the total amount of work to be done in the sprint and the length of the sprint is called the ideal line. This forms an isosceles triangle. In most burn down charts the amount of work remaining is also drawn between the two axes then compared to the ideal line. The difference between the two plots represents whether the project is ahead or behind schedule.

 

 Uses

There are two primary uses of a burn down chart; planning and monitoring. The burn down chart represents either what is intended to be delivered in a sprint in terms of stories or the amount of effort that is intended to be expended to deliver the agreed upon functionality. Through the quantification of what a sprint intends to deliver based on the estimates of the team and historical velocity, the chart represents a plan (a weakness for some that we will discuss later). The power of visual planning is even more evident when burn down charts are used for sprint and release planning for large programs.  

The second primary use of a burn down chart (and maybe the most important) is for monitoring and control based on the visual representations of the plan and progress against that plan. At a glance, the chart can tell whether you are ahead or behind schedule which provides the team with the impetus for action. For example, if progress is not being made fast enough additional effort can be brought to bear or scope can be reduced. Alternately, if progress is racing ahead of the ideal line, additional work can be accepted into the sprint.

Issues

A burn down chart can look like a roller coaster ride rather than the smooth slope that a glide path evokes. This saw toothed pattern reflects that both tasks and stories are not completed at the rate shown as the ideal slope. This rougher pattern suggests that it is important to know when a gap between the ideal and actual performance reflects a signal that action needs to be taken rather than the noise of the normal flow of work.  One solution I have seen used is to create a set of control limits (as if the burn down chart was a control chart) to create signals. Limits require making many assumptions about process discipline and capability that might not make sense. I would suggest that the use of mechanistic guides should only be used as a measure of last resort or perhaps as a set of training wheels. Rather, I would suggest relying on the judgment of the scrum master and team to provide the guidance needed to direct the sprint based on a strong definition of done.

 A second issue is that a burn down chart provides visibility at a high level rather than progress at a story level which causes some people concern. Burn down charts are not designed as a precise report on where each story is on a day-to-day basis but rather as a view of how much work is left to be done and whether the team is on track to meet its sprint goals. Those who expect the chart to have the same precision as a detailed schedule will not have their needs met. In order to meet the needs of those that need precise knowledge of individual stories, I would suggest a visit to the card wall or its proxy is a better source than the burn down chart.

An effective burn down chart used for monitoring and tracking effort needs to reflect the amount of effort required to complete the work defined by the sprint at specific point in time. In order to deliver this type of information the actual line can’t be a pure reflection of what is left of time originally planned rather it means that the actual line is something that is more like using earned value. The tracking of work remaining for any open task must become part of the daily rituals of the sprint team. I suggest that work left on a task be collected during the standup meeting and captured in the tool being used to track stories and activities. In one organization I was involved with a user field in TFS was created to track this data. Using this method, the actual line will reflect what needs to be done rather than just what was planned to be done.

A final issue with burn down charts is that it is not always easy to reflect changes in the number of stories while in flight. One simple alternative is the burn UP chart. Another options is to increase (or decrease) the ideal line at the point where the scope was changed or to extend the ideal below zero to reflect additions to scope. The former option is the one I suggest. This option can also be used when there are specific events that consume a significant amount of effort that are not spread evenly across a sprint.  

Related or Variant Measures

  • Functional Size
  • Velocity
  • Burn Up Charts
  • Earned Value
  • Productivity

 

Criticisms

The single most heard criticism is that a burn down chart does not provide as much status information as a project schedule or detailed status report (definitions vary). I would argue that the data presented is equivalent and if produced daily that it actually provide more actionable information and far less excuses. The real issue is that it is different and because it is different training and education are required. I do not suggest phased transitions as it is to easy to hold on to the past.

The false signal issue is a fair criticism. The saw tooth pattern seen in both effort and story denominated burn down charts require a conversation with the scrum master or team lead before reacting. Building an understand of how to interpret the burn down chart and building trust in self directed teams to see the trends and to take action themselves is critical for making a transition to this form of progress and status reporting.

The scrum master helps the team find the right road.

The scrum master helps the team find the right road.

In the movie Independence Day, the US President played by Bill Pullman, calls on his fellow pilots to help plow the field so that the character played by Randy Quaid can attack the alien craft. Pullman was facilitating Quaid though both a call to action and active participation. The scrum master’s job in most cases is to facilitate plowing the field for the team. This creates an environment for a team to grow and deliver value, while keeping outside influences from sapping the team’s energy. Here is the scrum master’s job description:

  • Responsible for ensuring that the Scrum practices and rules are followed.
    Ensure that the team is disciplined about the Agile practices and techniques that they have chosen to support team effectiveness.
  • Teaches the team by coaching and leading.
    The scrum master teaches the team how to use Agile practices and to deal with issues, rather than jumping in and supplanting the team’s actions.
  • Helps the team understand and use self-organization and cross functionality.
    The scrum master fosters an environment that helps the team become a team, rather than a collection of individuals. The scrum master helps to create this environment by asking questions, sharing problem solving techniques and mediating interpersonal differences.
  • Removes impediments.
    The scrum master facilitates the resolution of bottlenecks that are blocking the team’s progress.  When impediments are outside of the team’s ability to control (for example waiting on a deliverable from another team or vendor), the scrum master acts will pursue the problem so that others on the team can continue to be focused on delivering functional software.
  • Ensures that the team keeps itself functional and productive.
    The scrum master needs to observe how the team is working together and to facilitate action when the team is not performing optimally. The scrum master generally makes sure the team knows where they are during a sprint or iteration using tools like the burn down, burn up charts and card walls so that the team can take action.
  • Enables close cooperation across all roles and functions.
    Teams share work, provide support to each other and swarm to tasks or stories when needed.  In order to provide that level of support, it is import for all roles on a team to cooperate. This means that there can’t be a “us vs. them” relationship between any of the roles on the team. Team sharing and learning sessions are some the the techniques that scrum masters can use to teams learn each others roles and functions.
  • Shields the team from external interference.
    At times outsiders will pull at team. External interference is a specialized form of an impediment that tends to drain time or focus from the team. The scrum master will deflect or absorb as many requests that will take the team’s focus away for meeting their commitments and delivering value.

The scrum master needs to create an environment for the team to prosper. The list above outlines the responsibilities that the scrum master must tackle to be effective. As you can see, a scrum master is more than an administrator or planner. The scrum masters facilitates the whole Agile team in attaining their the ultimate measure of value by focusing on the people on the team’s needs and how they are using the process.

Book Cover

 

This week we re-read Chapter 3 of Thinking, Fast and Slow by Daniel Kahneman. One of the core themes in this chapter is the concept of ego depletion.  Ego depletion is a theory that self-control, as a form of system 2 thinking, draws from a finite pool of mental resources. When the pool is low, so is self-control. I did some research on the topic and the evidence is mixed whether there is an ego depletion impact. Regardless, from the point of view of Chapter 3 the idea is that heavy mental and physical loads on a person spread their ability to think and make decisions thin is not a stretch (and we should not expend a significant cognitive load on the topic). Whether the triggering mechanism is ego depletion or something else is not as important as the observable impact – when people are under mental stress they don’t always make the most thoughtful decisions.    (more…)

Today we continue our journey through Bad Blood, Secrets and Lies in a Silicon Valley Startup by John Carreyrou (published by Alfred A. Knopf, 2018).   Today we tackle chapters one and two. They are titled, “A Purposeful Life” and “Gluebot.”  I have not changed the estimate of 20 to 25 weeks, however, Steven Adams has thrown down the gauntlet by suggesting we can do more than two chapters a week.  We shall see!
(more…)

Book Cover

In week eight of the re-read of L. David Marquet’s Turn the Ship Around! we continue to explore the heart of Marquet’s leadership model.  This week the two chapters are Underway on Nuclear Power and “I Intend to . . .”. Chapter 11 is one of my favorites.

Chapter 10: Underway on Nuclear Power

The framing question for the chapter is, “Do you play “bring me a rock “in your organization, where vague understanding of the goal results in wasted time? (more…)

Book Cover

 

In week four of the re-read of L. David Marquet’s Turn the Ship Around! we tackle Chapters three and four. These two chapters, titled Change of Course and Frustration, continue to build the basis for Marquet’s leadership model.

Chapter 3: Change of Course (more…)