Agile Development Blog

#5 in our list of the Top 10 characteristics of an Agile organization is about the importance of practicing both Bottom-up and Top-down decision making.

In this 4 minute video, I talk about how successful Agile organizations embrace a notion of the ‘knowledge-creating company.’ In Agile, knowledge-creation can use “5 Levels of Planning” to ensure they are engaging in this whole organization practice. In sum, the highest level of planning, the vision, feeds and is fed by all subsequent levels, down to the lowest level of planning, the detailed daily work.

Watch my video for more about why I truly believe in both Bottom-up and Top-down decision making as a key success factor.

See our previous coverage of #10 Work/Life Balance, #9 Being a Servant and Leader, #8  Sustainable and Successful, #7 Contributing to the Community and the Company and #6 Collaborative and Smart. Stay tuned for #4 in our series, Personal Flexibility and Rhythm.

Okay, I must be obsessed with Agile and PMOs lately. Well, Lean, too, as long as we are talking about obsessions.

Recently, I posted two blogs on the PMO topic: “Are PMOs Obsolete in Agile?” and “8 Ways to Re-tool a PMO in an Agile Environment“.

Now, in the upcoming Better Software Conference June 8 through 12, I will be presenting “Agile, Lean and the PMO”.

To summarize and entice, let me give you a quick preview.

PMOs usually think they are out of a job when Agile comes to town. But the truth is that a PMO can play a pivotal role in successful Agile adoption in large organizations.  In this presentation, I bring my experiences guiding organizations in how to engage their PMOs for successful Agile Adoption.

Enter three primary Lean Principles:

• Eliminate Waste
• See the Whole
• Amplify Learning

I intend to give examples of how PMO members act as the “systems thinkers” for their organizations, pulling Agile success outside of the engineering group alone and into the entire enterprise.

As I’ve stated before, there is a fundamental shift of the role of the PMO with Agile.

Simply stated, the PMO pulls standards versus pushing them;  the PMO provides product backlog prioritization guidance with regard to architecture and governance; and the PMO serves its Agile community by facilitating release planning across teams and creating and maintaining product councils.

In short, I contend that a truly Agile PMO brings “shocking openness” to the organization. This ensures deep, wide Agile adoption.

Let’s get together in Vegas to talk about PMOs and Agile and how Lean can guide us to take “what happens in Vegas” back to our organizations!

In an earlier post, I asked an Agile test question, “Are PMOs Obsolete in Agile?”

While the answer MAY be “Yes!”, I posited that there may be a way to save our PMOs from going the way of the now extinct dodo bird.

8 Ways To Re-Tool a PMO in an Agile Environment

1. Have the PMO involved in helping rollout Agile on several pilot projects

   This experience forms the roots for how the Agile PMO will engage throughout the organization with other project teams.

   Besides ensuring that Agile training occurs, the Agile PMO can become the coaches of coaches, training the ScrumMasters of each team. They can also be the Agile voice into the business to ensure the Product representatives are fully bought into their role in Agile.

2. Learn from Lean: start a Kaizen and Gemba mentality now

   The PMO should be the shepherds of continuous improvement so that the Agile adoption is not only sustained; it is vibrantly organic, every improving. This means moving beyond team-level iteration-focused retrospectives.

   Kaizen events create cross-team learning. This learning exposes team practices that can be useful at an organizational level. In such cases, the team practices are elevated to the organizational “Standard of Work” (see later item). Moreover, the Kaizen event clarifies when a practice does not serve the entire organization and can remain a team practice, supported by team agreements and adhered to by the team.

   In addition, in between Kaizen events, apply “Gemba”. An Agile PMO learns about the organization and spreads knowledge through the organization by being involved in projects. That means going to see, or “Gemba” according to Lean practices.

   Being engaged with teams rather than dictating from afar may be a dramatic shift in PMO behavior. And, it is pivotal to teams’ respecting the role of the PMO in creating a successful Agile adoption.

3. Change your definition of “Standard of Work”

   This is not a set of standards defined by and enforced by the PMO for project conformance.

   In Agile, as guided by Lean practices, a standard of work is a statement of what is currently useful, how things are currently done. It provides a team a backdrop from which to perform continuous improvement through Kaizen events such as retrospectives.

   (In my previous post on the PMO, Brendan Flynn has a wonderful comment about how he and his PMO engage teams at Shoplocal in doing this work.)

4. Facilitate and be a Servant Leader

   Don’t control.

   The Agile PMO, rather than controlling and patrolling, engages in facilitating teams in continuous learning. This PMO encourages empowered teams and amplifies the learning that arises when such teams are truly empowered.

   A great way to provide this facilitation and to engender cross-team involvement is to help organize and facilitate program-level and multi-program release planning meetings and product councils. The Agile PMO formulates a rhythm and a continuously improving agenda to help these meetings deliver the greatest benefit across teams.

   Along with being facilitative, Agile PMOs act as Servant Leaders. They serve their organizations by finding out what they need and getting it for them.

   They lead by serving. They remove impediments. They measure what is a problem for teams so that they can serve teams be removing the problem. They don’t look for status from teams; they look for how they can serve teams.

   So, for an Agile PMO, leading the Agile rollout means finding out what teams need and delivering that. It is about creating collaborative plans, not collecting statuses. For more about Servant Leaders in Agile, check out the first section of my book Collaboration Explained.

5. Provide guidance on regulatory adherence

   In organizations that must adhere to Sarbanes-Oxley, FDA, HIPAA, or other regulatory guidelines, the Agile PMO can represent these “red” (immutable) stories in each team’s Product Backlog.

   The PMO governance work can be the guide to each Product Owner on how to deliver the documents or features that help the entire organization remain in compliance with these regulatory constraints. Governance is now a service to project teams versus being a control mechanism.

6. Seek guidance from Lean to use Flow, Pull, and Innovate as guidelines for organizational-level Agile adoption

   Much of the guidance here has a hint of Lean about it. That is because PMOs work at an organizational level. Moving Agile beyond one or more pilot teams requires guidance for maturing and scaling.

   I recommend applying a 5-step approach which is based on Full, Pull and Innovate principles from Lean Thinking.

   Our Rally whitepaper about Applying Lean Pull principle for Program level Agile is a great guide for the Agile PMO working with programs of teams.

7. Guide non-IT/Engineering organizations

   Once Development group is working with the business to deliver prioritized, valued items, the Agile PMO can bring in other ‘back office” functions to help ensure a growing Agile adoption.

   Finance, HR, infrastructure, the executive team, and others must eventually all accept the Agile approach for true organizational change and value.

   The Agile PMO has an opportunity to be the mentors and guides for this growth and maturation.

8. Foster useful metrics

   Let go of that Waterfall security blanket around what are useful project or program metrics.

   Determine which metrics to track that directly help organizations concentrate on value delivery.

   Whatever does not deliver value is waste. It may be temporarily necessary waste. Or it may be a pernicious, embedded waste that has been assumed to be necessary.

   An Agile PMO ferrets out these “false friend” metrics and works with teams to determine metrics around value: test coverage, team velocity, agile adoption assessment, defect counts, definition of done.

   Look in the Appendix of our whitepaper A CIO’s Playbook for Adopting Scrum for more ideas on useful metrics in Agile adoption.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

note: PMO stands for Project Management Office.

To PMO or not to PMO? That is the question. Or, put another way, in our Agile test this week, please answer the following question:

Are PMOs Obsolete in Agile?

(a) YES!

(b) NO!

(c) Uh, maybe?

(d) All of the above :- )

What’s your answer?
Before you tell me, here is some food for thought:

Archeological Dig for Extinct Life Form

(a) YES!

Yes, if your PMO maintains a  rigid conformance posture informed by Waterfall approaches to managing and tracking project risk and success, it is obsolete. Lose it. Here’s why:

• Agile has no place for rigidity.

• Agile rewards flexibility, responsible change, and continuous growth. This is true in processes, in practices, and in people.

• Agile doesn’t seek conformance. Agile seeks emergence of the most useful, sustainable practices that deliver value, team by team, item by item, timebox by timebox.

• A PMO that determines standards and then enforces these standards through status updates runs counter to the core of Agile.

• Agile seeks more than status updates. There is no punishment or reward system other than finding impediments and removing them.

A conformance-based PMO, in contrast, will tend to hold onto old habits: create standards; enforce their standards; collect detailed status information about how projects are conforming to their standards; create pressure to bring non-conforming projects into line. Such a PMO can inadvertently (or purposefully?) create a culture of blame and hence engender skewed reporting by projects in order to avoid associated “punishments” or public flogging. This PMO with its incumbent culture will absolutely kill an Agile initiative before it has started.

So, if you find yourself in this environment, lose the PMO or you will never win with Agile.

(b) NO!

If your PMO is prepared to be a liaison and evangelist of the Agile rollout across the organization, don’t lose them! They can be a pivotal force that ensures the true essence of Agile; they seek to find out what delivers value in a regular rhythm and to keep improving on it.

The PMO has an incredible vantage point in an organization: they can look around and “see the whole”. Heads-down Agile project teams concentrate on what works in their singular context. An Agile  PMO, on the other hand, with a broader view, has the golden opportunity to continuously survey project teams to learn from them what is working well and then spread that good news to other teams and to the management.

An Agile PMO applying Lean Principles such as eliminating waste and amplifying learning can serve as the servants to the Product Owners and ScrumMasters. They can support the Agile project teams by facilitating cross-fertilization of best practices. They become the guardians and carriers of the Agile emergence. You might say they are act as the Agile pollinators.

Note: see my post “8 Ways To Re-Tool a PMO in an Agile Environment” for further information about how to create an Agile PMO.

(c) Uh, Maybe?

Ultimately, it comes down to this: What transitional fortitude does your organization have to move to a new way of doing things: the learning, the facilitation, and the Servant Leadership required of an Agile PMO?

That is the big MAYBE that will be sitting like an elephant in the room with you as you consider an Agile rollout with your PMO.

My Rally colleague Mark Kilby has a great way of testing this: Is your PMO prepared to sign an Agile PMO Manifesto?

We, as an Agile PMO, value:

• Kaizen (retrospections for continuous improvement) over Conformance and Consistency
• Org-team mutual Service Level Agreements over Top-down Policies and Processes
• Communities of Practice over Central Authority

(d) All of the above :- )

So, where are you, where do you want to be, and how do you hope to get there? You may, at any time, be any one of the above, or all at the same time. Fear not! There is a way.

Just remember, answer (a) YES! reminds us that a traditional PMO has no place in a  truly Agile organization and is hence obsolete.

To get to answer (b) NO! your PMO must be prepared  for jolting change in its principles and practices. It may seem daunting. But Agile and Lean have great guidance to protect you along your path.

And, at any time during your Agile Adoption, you may find yourself in the ambiguity of (c) Uh, Maybe? or (d) All of the above :- )

If you are prepared to embrace the 10-step Agile PMO guidance and Mark Kilby’s Agile PMO Manifesto, you will be on the righteous Agile PMO path.

So, now tell me your answer to the question: Are PMOs Obsolete in Agile?

Question: How did you get started from waterfall?

Answer 1 -  Started with whiteboards and sticky notes.

Answer 2 – Started with in-house tool, then open source and finally Rally.

Answer 3 – Started with Rally training for the first year with a Rally pilot in parallel to show management and staff the whole solution.

Answer 4 – Put good consultants alongside the team from day 1 to apprenticeship with the best – we went Rally training and consulting.

Question: We have lots of concurrent features in parallel. Does anyone do concurrent feature branches?

Answer 1 – Peggy – At Avaya we do this, but first go back to the product owner to prioritize better.  We use private views in ClearCase to manage features branches with continuous integration in the views.

Answer 2 – Israel – Never allow the backlog to be larger than twice the capacity of a release.

Question: Please talk about the adoption challenges of adopting with your external customers.

Answer 1 – Israel – It took us 18 months to change the perception of my group with sales.  It was critical to get field engineers to come to release planning and every iteration demo. They get exposed to the software engineering approach and real status and built the best evangelists and advocates in the process.

Answer 2 – Richard – Rally has developed a social networking site with what most people see as shocking openness.  As a result, we have had tremendous success in engaging customers and focusing priorities.

Question: What is the cheapest and best way to get started as an individual?

Answer 1 – Take trips to visit other local companies – everyone says yes.

Answer 2 – “XP in Trenches” – was recent great book find- read a ton of books but most only focused on single team.

Answer 3 – Richard – Come be a fly on the wall at a Rally release planning.

Question: Big Six Sigma background – What tools do you use QFD to find what customer really wants?

Answer 1 – Failed with all upfront tools, only thing that works is communication in every iteration.  Too many edge cases in our industrial software.  Given up trying to spec this in advance.  Invest more in bringing the customer in.

Answer 2 – Israel – Try to reach the point where the developer can code faster than marketers can release.  As soon as that happens, you can decouple and get more feedback during the cycle.  You are also able to bring more of the business into learning after you decouple.

Question: How do you solve the coordination of many teams in a large adoption? Tell me more about Meta Scrum.

Answer 1 – We do a meta scrum every week with the owners of seven product lines.  In parallel the product owners and development leads do the same.

Answer 2 – Israel – Scrum of Scrums everyday with all the ScrumMasters following a 10 to 15 minute approach.

On Thursday, March 19th, Dave West from Forrester Research and I will be doing a live webinar titled, “Scaling Agility with Lean: Proven Methods of Operational Efficiency.” It is part of a webinar series regarding “Using Agile to Cut Development Costs.” Our own Jean Tabaka and Global Logic’s Johnny Scarborough did the first webinar titled “Realizing the Promise of Agile: Creating Leaner, Meaner and Faster Product Development” and it is available via recording by registering at this same site.

In this week’s webinar, I am going to share a set of models that I  keep being asked about. These slides show the changes that happen in the enterprise stage gate model as your Agile adoption moves up and matures in the organization. To hear the explanation behind these slides and see Dave West’s work on Lean, please join us on the webinar.  The full slide deck will be available after the webinar.

Not to steal all of my thunder, but there are two things that interesting about this transition.

1. The Agile stage gates of 3.1/4.1 actually provide more governance control than the old gates.
2. The first and last gate are not going away in large organizations anytime soon. You just don’t start projects without budget and you do not make a gold master for production without blessing from operations or overall system testing.

Lastly, Dave’s observations about how these stage gate models require a Lean organization approach, should make for a great conversation. I hope you will join us.

Original F4 Technologies logo 2002-2004

I know what you are thinking with the title of this post – I am drinking the Kool-Aid. Just bear with me  for a minute. Back in 2002, when I started working on Rally, it was originally known as F4 Technologies. It was known as F4 because I did not want to work on anything that did not have the potential impact of a Factor of Four, for example a 4X increase in productivity or effectiveness.   There are two reasons for this:

1. Andrew MacAfee and John Gourville at HBS have shown that you need a 9X improvement with a new tool, technique or method to un-seed the incumbent.
2. According to Paul Hawken in Natural Capitalism, we need a 4X productivity increase in the use of natural resources to get to a sustainable place with the current population in the world.  Chapter 7 of that book helped form the core purpose and mantra of Rally – “Muda, Service and Flow.”

Now seven years into Rally, we have the proof that teams – including large and distributed teams – can be 4 to 10X more productive by following Lean principles and effectively implementing Agile development.  Like the story of “Good to Great”  from Jim Collins, you can’t leap here, but you can put yourself on that path by adopting a continuous improvement approach like Agile.  If you do that, you can be a “great” software development organization that dominates your market and is 10X better than the good ones.  Great organizations that dominate in their industry also have the knowledge and resources to change world, a la Google.org, the Salesforce.com Foundation and or through my favorite the Entrepreneur’s Foundation.

My summary take-away from Good to Great is:

“Right people building the right things right”

“Disciplined people, Disciplined thought, Disciplined culture “

If you are working toward this, I believe you increase your business value by 4 to 10 times.  I am going to make the case with the help of ROI models from David Anderson.  (BTW, I love his book – it does a great job explaining the simple physics of Agile.)

From Chapter 2 - David Anderson's "Agile Management for Software Engineering"

This is a very simple model of software process.  David shows more complex ones that model all the loop backs of large shipping software, but let’s work with this one.  So, the rough equations to calculate the business benefit of the process are the following:

Net Profit = Throughput – Operating Expense 
ROI = Net Profit / Investment

In the following four pages, I am going to look at how this equation plays out for four different scenarios:

1. Good waterfall team, on the mean line of the QSMA Agile Impact Report
2. Beginning Agile team in Flow benefiting from the 25% productivity savings of an Agile teams in the same study
3. Intermediate Agile team in Pull with incremental releases of value
4. Advanced team in Innovate that cuts time-to-market in 1/2 to end early after delivering 50% of the work but 80%the value

What you will see in this hypothetical modeling exercise is the true power of Agile to dramatically impact the software development teams in the organization. For a deeper understanding of what I mean by Flow, Pull and Innovate, please Jean and I’s white paper on moving to Program Pull.

Here is the summary:

1. Good waterfall team – ROI – 0.8
2. Beginning Agile team in Flow  – ROI – 1.4 (1.6 factor better than good waterfall team)
3. Intermediate Agile team in Pull  – ROI – 2.6 (3.2 factor better than good waterfall team)
4. Advanced Agile team in Innovate  – ROI – 6.3 (7.7 factor better than good waterfall team)

Factor or Four or better – that is why there is such a rush towards Agile development.  Of course, you can’t have your cake and  eat it too.  Moving up this maturity curve takes long-term dedication to increasing discipline and agility across the entire organization, but there are dramatic benefits if you can get on the continuous improvement path and stay there.

In my post “What’s with all the Agile Process Overhead? Part 1″, I reviewed the contents of the Sprint  Backlog. Hold, commit to, and track items of value there. Nothing else.

I eluded to two other perceived Agile Process overheads, one of which I’d like to peek at today: how do you allocate your time effectively?

This came about from the same client discussion that prompted the post on the Sprint Backlog. In conversation, I discovered that the team believed that they had to be 100% allocated for the entire duration of their Sprint. Hence, the lengthy, detailed nature of their Sprint Backlog. Time to back up.

Team Members determine their ideal effort availability

We’ve already covered one problem with this allocation paradigm: you are tracking the wrong thing in your Sprint Backlog if it is not showing value-add work completion. Now, here is the second villain. No-one can accurately account for all hours of every working day as “ideal effort hours”; that is, hours of completely uninterrupted, undistracted work. Ravi Jha stole some of my thunder on this with his great comment to my previous post. Heed his advice from February 27!

Teams preparing to plan their commitment for a Sprint/Iteration look at their capacity; that is, how much work do we believe we can take on and complete by the end of the Sprint? As Ravi pointed out, a good team assumes from the start that it cannot devote a full 8-hours a day strictly to product backlog value-add work. A good beginning capacity number is 6.  Why 6? Because it is not 8. Until informed otherwise, of our 8-hour work day, we believe each of us can truly be heads-down concentrating for 6 of those hours. The rest of the time will be swallowed up by interruptions, emails, unplanned meetings, and other distractions.

Now, here is the sticky part. As I mentioned in Part 1 of this series, Agile teams must also take into account slack for what they can’t know. This is different than the 6 hour number of ideal effort hours. When we make a commitment in a Sprint Planning meeting, the commitment is:

• We are committing to moving forward with what we currently know so that we can continue to learn by building a potentially shippable increment of the product.
• Our intention is to complete all of these Sprint Backlog items based on the analysis and conversation that has happened to this point.
• We think it will take these many ideal effort hours and we believe we have this many hours available.
• Everyday, we will honestly evaluate how we are doing with our commitment so that we can improve on meeting this commitment AND improve on how we make commitments in the future.

Therefore, a team, not knowing what it doesn’t know, applies a certain additional level of slack or buffer to how it commits. Call this the “Commitment – Buffer of Unknownables” (or C-BOUs). Now the team that has 6 uninterrupted hours per team member per day may additionally say, “Our C-BOU is about 1 hour person right now per day because we just don’t know this product or this process very well. We don’t know what we don’t know, though we know we want to get better.” As the team evaluates the Product Backlog Items with the Product Owner, and as they determine tasks and estimates for this work, they are keeping in mind:

• what ideal hours they will need
• what ideal hours do they have
• how much C-BOU should they hold back

By the end of the Sprint Planning meeting, a commitment then truly represents:

• Items of value we intend to deliver
• Commitment by the team to learn about commitment
• Intention to use the buffer for what they couldn’t have known
• Agreement to evaluate the C-BOU at each retrospective to see if it needs to be bigger or smaller

Some teams call for a bigger C-BOU due to the volatility of their environment. (Okay, they prefer to say their business is very “organic”.) Tracking this capacity buffer is a great way to enable getting to the root of that “organic” nature. Without paying explicit attention to the truth of unknowns and the amount of time they take, a team and the agile project management can create waste and overhead. Teams go into a frenzy mode to meet a commitment that allowed for no buffer, no unknowns. Management applies pressure to meet the commitment despite the clear and present issues that are eating up the efforrt. None of these tactics improve team commitment; they create overhead, waste, and low morale. And they add the cost of manaing all three of these.

That’s it for Part 2. In Part 3, I’ll talk about how you plan for unplanned work, without using a crystal ball :- )

In my last post on Agile Cuts Costs Through Time to Market Improvements, we talked about the 50% savings that are available, but I did not go into why or how Agile teams have the ability to do this.  Time to market improvement in agile project management come conceptually from combining three aspects of agile development. First, the team commits to the discipline of delivering small batches of working, tested increments of “potentially shippable units” of functionality in small time boxes.  Second, the team works with the product owners and customer to sequence those small batch increments into an order that delivers the most valuable features first, in terms of customer value or technical risk reduction.

Investment and payback curve of a software project - Adapted from the book Software-By-Numbers

When a software development team adopts these two principles at acceptable quality levels, beautiful things happen!

1. They shorten the time to feedback and they can now adjust based on customer feedback
2. They open themselves up to shipping early based on delivering value fast
3. They sample faster and increase their ability to react to changes around them

Visually, it would be like shifting the discounted cash (red line) up and to the left. The investment and payback periods become shorter and break even comes sooner.  In addition, because you are delivering working increments sooner with tons of visibility, the risk of the project goes down over time.  (See the picture below.)

Risk only goes down because the time to feedback is shortened and acted on, as shown in the waterfall vs. Agile chart. Factoring the feedback from the visible iteration demonstrations and retrospective into the next round of planning is necessary to enable Agile’s empirical governance model.  This “inspect and adapt” governance approach made famous in Scrum makes agile project management work through active learning and continuous improvement.  This is the critical third pieces of what allows folks to deliver 50% TTM benefits, without it Agile teams can just iterate into a dead-end or black-hole.

With regard to sampling faster, I tend to coach teams to “deliver releases” at least twice as fast as the market or customer requires.  That allows you to get feedback on what was delivered and adjust to changes in the customer environments. (“Deliver releases” does not mean incur all the costs of shipping software, but it does mean create a potentially shippable unit that exercises all your system and integration testing muscles and allows you to get your software into your customer’s hands for trial and feedback.)

Finally with regard to shipping early, Tim Lister of the Atlantic System Guild and Waltzing with Bears/Peopleware fame gave a talk about the potential outcomes of projects at the Agile 2006 conference.  He was talking to his dad about the outcomes of IT projects as on-time or late.  His dad asked him about the other option that apparently no one in IT thinks of – early! Agile teams are always thinking about the option and value of shipping early for feedback.

The great thing about TTM savings is that these savings are mostly independant of productivity savings that I mentioned in an early blog post.  Next post is how Agile Cuts Cost by building the “right” software that actually get’s used.  Finally, I will talk about how these savings and behavior changes play together to deliver astonshing results over time.

In this post, I’d like to comment on a request from a Rally client I recently visited. Their tool request? A burndown chart for each individual. We were in a small meeting and my intent had been to help them with their Agile adoption. “No, Jean, it is your Rally tool that is the problem.” Hmmmm. Let’s take a look. What seems to be the problem?  “Your tool is not helping our ScrumMaster and management team track individual team members’ burndown during the Sprint. We absolutely have to have that.” Huh?  I had to call foul and get the group to step back and talk about “What’s in a burndown chart and why?”

Individual team member tracking in a burndown chart is a bad smell. It suggests that the commitment made in the Sprint Planning meeting is not a team commitment. It also suggests that the management is not tracking value delivery, but rather team work. I dug further with this group about that. Each individual at this organization was expected to commit exactly to the number of hours any of their tasks would take, and stick to it. That commitment was meant to never change. If a team member was “taking too long” (which they claimed could only be known via individual burndown charts), management would then be able to “do something” about it. What happened to the Daily Standup for team check-in? But I digress.

Tracking in a burndown chart is meant to trace team commitment around the valued items it intends to deliver. At the end of the Sprint Planning meeting, it reflects the team’s initial estimate of effort to achieve that value delivery. During the Sprint,  the burndown chart reflects daily, “Are we going to meet our commitment to delivering this value? If not, what is the single most important, the highest priority thing we must do today?” Finally, the burndown chart  informs the Sprint Demo and Review about what happened with the team’s commitments to value delivery  versus what they were able to complete.

What’s in a name? Well, when it is a burndown chart, there are three things:

1. charting the initial Sprint Planning meeting team-wide commitment to the valued items the team can deliver in a timebox
2. prompting the daily inspection of what is the most important thing the team must do today to meet that commitment
3. informing the the team at Sprint review to evaluate how the team’s estimates and commitment compared to what value the team was able to deliver

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.