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.

This week…I am hiking in the woods without my laptop albeit I do have my copy of  Monotasking by Staffan Nöteberg. I am continuing to focus on using shortlists, which has been a fairly easy transition and also implementing both the panorama cues and panorama sessions. The panorama cues and sessions have been useful up to the point that my dairy becomes wall-to-wall meetings.  I am trying to devise an approach for using panorama sessions in this scenario.  Suggestions?  While I am out in the woods I have re-published the summary of one of the most popular Re-reads, The Goal.  We will be back to Monotasking by Staffan Nöteberg next week.

Re-Read Saturday: The Goal: A Process of Ongoing Improvement Summary

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast. Dead Tree Version or Kindle Version

Chapters 1 through 3 actively present the reader with a burning platform. The plant and division are failing. Alex Rogo has actively pursued increased efficiency and automation to generate cost reductions, however performance is falling even further behind and fear has become central feature in the corporate culture.

Chapters 4 through 6 shift the focus from steps in the process to the process as a whole. Chapters 4 – 6 move us down the path of identifying the ultimate goal of the organization (in this book). The goal is making money and embracing the big picture of systems thinking. In this section, the authors point out that we are often caught up with pursuing interim goals, such as quality, efficiency or even employment, to the exclusion of the of the ultimate goal. We are reminded by the burning platform identified in the first few pages of the book, the impending closure of the plant and perhaps the division, which in the long run an organization must make progress towards their ultimate goal, or they won’t exist.

Chapters 7 through 9 show Alex’s commitment to change, seeks more precise advice from Johan, brings his closest reports into the discussion and begins a dialog with his wife (remember this is a novel). In this section of the book the concept “that you get what you measure” is addressed. In this section of the book, we see measures of efficiency being used at the level of part production, but not at the level of whole orders or even sales. We discover the corollary to the adage ‘you get what you measure’ is that if you measure the wrong thing …you get the wrong thing. We begin to see Alex’s urgency and commitment to make a change.

Chapters 10 through 12 mark a turning point in the book. Alex has embraced a more systems view of the plant and that the measures that have been used to date are more focused on optimizing parts of the process to the detriment to overall goal of the plant.  What has not fallen into place is how to take that new knowledge and change how the plant works. The introduction of the concepts of dependent events and statistical variation begin the shift the conceptual understanding of what measure towards how the management team can actually use that information.

Chapters 13 through 16 drive home the point that dependent events and statistical variation impact the performance of the overall system. In order for the overall process to be more effective you have to understand the capability and capacity of each step and then take a systems view. These chapters establish the concepts of bottlenecks and constraints without directly naming them and that focusing on local optimums causes more trouble than benefit.

Chapters 17 through 18 introduces the concept of bottlenecked resources. The affect of the combination dependent events and statistical variability through bottlenecked resources makes delivery unpredictable and substantially more costly. The variability in flow through the process exposes bottlenecks that limit our ability to catch up, making projects and products late or worse generating technical debt when corners are cut in order to make the date or budget.

Chapters 19 through 20 begins with Johan coaching Alex’s team to help them to identify a pallet of possible solutions. They discover that every time the capacity of a bottleneck is increased more product can be shipped.  Changing the capacity of a bottleneck includes reducing down time and the amount of waste the process generates. The impact of a bottleneck is not the cost of individual part, but the cost of the whole product that cannot be shipped. Instead of waiting to make all of the changes Alex and his team implement changes incrementally rather than waiting until they can deliver all of the changes.

Chapters 21 through 22are a short primer on change management. Just telling people to do something different does not generate support. Significant change requires transparency, communication and involvement. One of Deming’s 14 Principles is constancy of purpose. Alex and his team engage the workforce though a wide range of communication tools and while staying focused on implementing the changes needed to stay in business.

Chapters 23 through 24 introduce the idea of involving the people doing the work in defining the solutions to work problems and finding opportunities. In Agile we use retrospectives to involve and capture the team’s ideas on process and personnel improvements. We also find that fixing one problem without an overall understanding of the whole system can cause problems to pop up elsewhere.

Chapters 25 and 26 introduce several concepts. The first concept is that if non-bottleneck steps are run at full capacity, they create inventory and waste. At full capacity their output outstrips the overall process’ ability to create a final product. Secondly, keeping people and resources 100% busy does not always move you closer to the goal of delivering value to the end customer. Simply put: don’t do work that does not move you closer to the goal of the organization. The combination of these two concepts suggests that products (parts or computer programs) should only be worked on and completed until they are needed in the next step in the process (Kanban). A side effect to these revelations is that sometimes people and processes will not be 100% utilized.

Chapters 27 and 28 shows the results of focusing on the flow of work the bottleneck and only beginning work when it will be needed has improved the results at the plant,  Bill Peach pushes Alex for more using the threat of closing the plant as the stick to make the threat real.  Johan suggests cutting batch sizes in half as a way to improve performance and urges Alex to let the sales team know the plant can deliver quickly and quality.

Chapter 29 and 30 show that the plant has been able to deliver on the huge order from Bucky Burnside, the company’s largest customer, without impacting other orders or sacrificing quality. In order to meet the new demands on the plant, they reduced batch size again, which improved flexibility and efficiency. Burnside is so thrilled with the results and the staggered delivery schedule he flies to the plant to shake the hand of every production worker. Jons, the head of sales, confides to Alex that the success has led to the promise of even more business from Burnside. Despite all of the success, it is time for the plant review.

Chapters 31 and 32 deal with the plant review and the review’s immediate aftermath. Alex defends the changes he and his team have made to how work is done in the plant. The defense includes a summary of the theory of constraints. While Hilton Smyth is hostile, Alex’s performance has been noticed and Bill Peach tells him that he is to be promoted. Alex immediately reaches out to Johan who tells him that in the future he will need to trust his own judgement.

Chapters 33 and 34 reflect a shift in focus. With the plant saved, Alex is faced with a need to generalize the process that was used so that it can be used for different problems or scaled up to the next level based on his promotion. The problem is that finding a generalized process is hard and unless Alex and his team can find a way to generalize what they have done it will be difficult to replicate across the division.

Chapters 35 and 36.  Alex and his team struggle to generalize a process that Alex can use when he begins his new job based what the whole team has learned as they turned the plant around.  The process they find is:

  1. Find the bottleneck in the flow of work.
  2. Decide how to “exploit” the bottleneck (make sure you maximize the flow through the bottleneck).
  3. Subordinate every other step to the bottleneck (only do the work the bottleneck can accommodate).
  4. Elevate the bottleneck (increase the capacity of the bottleneck).
  5. If the bottleneck has been broken repeat the process (a bottleneck is broken when the step has excess capacity).

As chapter 36 concludes the team reflects that the word bottleneck should be replaced with the slightly broader concept of constraint.

Chapters 37 and 38. Alex and his team continue to struggle to answer Johan’s final question.  During their discussions Alex and his team find that the plant has 20% extra capacity.  With the understanding that the plant needs (and can) to increase production, Alex, Lou and Ralph meet with Johnny Jons to explore new sales opportunities. Jons has a pending order that the plant can accept and is above variable cost of production.

Chapters 39 and 40 wrap Alex’s journey up.  In these chapters Alex finally answers Johan’s question, “What are the techniques needed for management?” During a  struggle to apply the five focusing questions to help the entire division leads Alex to the conclusion that, to manage, a leader must have the techniques to answer these questions:

  1. What to change?
  2. What to change to?
  3. How to cause the change?

Alex realizes he has learned to think for himself which was the outcome Johan had hoped for when he stopped providing advice.

The sprint backlog is the work teams do on a day-to-day basis. A sprint backlog is a tool that the team uses to guide their activities. The backlog is a combination of outputs of other activities such as the sprint goal, accepted product backlog (not the same thing as the sprint backlog), and at least process improvement items and activities, such as sprint planning and day-to-day planning. Quite a mouthful. A less complete but more easily understood description of the sprint backlog is “the things the team needs to do to deliver value.” The sprint backlog gets created over and over during sprint as they discover information and knowledge.

(more…)
Book cover: Tame your Work Flow
Tame your Work Flow

A few logistical comments before we dive into chapter 20.  After this week we have three weeks left in this re-read including our customary debrief. When we decided on Tame your Work Flow we decided on the next two books in the series due to the intense competition, so in four weeks, we will begin Jeff Dalton’s Great Big Agile.  We will only read the part of the book that addresses the Agile Performance Holarchy. This is not a slight to the rest of the book which includes a wide range of tools and techniques that are consumable (I keep a copy close at hand) and do not need further analysis. 

(more…)

One of the classic issues that pop up when teams chronically don’t complete work they say they will, in the time they say they will is that they are taking too much work at once. Being somewhat hyperbolic, I liken it to eating a very large hamburger (for example) in one bite. Even if it is possible to shove the whole thing in, it would be painful to swallow. I have facilitated more than a few retrospectives that discussed taking on more work than is completable in a specific timebox. Several of the reasons that generally surface:

(more…)