Visualize Progress

Leaders need to understand what their teams are building, how far along the work has progressed, and whether that work is on, ahead of, or behind schedule.

Note that leaders can’t manage or change “progress” itself, team speed is a fixed velocity in the short to medium term. It’s important to know the state of the product development and consciously avoid reflexive actions that make bad matters worse. At Level 2, you can use Manage Priorities to effectively manage the data from this practice.

First, do no harm.

Pain Points

  • No management-level visibility into the team’s work or progress
  • Management has no view of the teams ability to create working, tested, features ready to ship
  • Too many failed projects that looked viable until the last minute
  • Projects that consistently slash features at the last minute to meet dates
  • Projects that consistently shift the ship date
  • Frequent micromanagement because it’s the only way to have a chance of understanding the team’s progress


  • Incremental visibility
  • Coarse-grained predictability
  • Early performance indicators


  • Management can run the current set of working, tested features ready to ship (100pts)
  • Management can see product progress via big visible charts (50pts)
  • Teams have an established trend to predict future capacity (50pts)
  • Managers have no ability to predict future capacity (-50pts)
  • Product progress is buried in the bowels of a tool (-100pts)
  • The teams cannot build the product for review (-100pts)
  • There is no visibility into the current state of work in progress (-250pts)


✓ Critical ❑ Helpful ❑ Experimental

Depends on: Vision

Adoption Experiment

Steps to first adopt this practice:


  1. Verify teams are using the team Stage 1 practice Timebox and are accepting and completing work that fits inside those timeboxes
  2. Ensure that the DeepProductDiscovery has occurred and work is contained in features
  3. Track historical size of features and how many stories per feature


  1. For your upcoming release, track completed features vs the features pulled in during release planning
  2. Create a burn up chart showing progress, especially any change in the number of features in the release

Evaluate Feedback

  1. Compare the progress of completed stories and features vs your traditional tracking techniques
  2. Use the burn-up charts trend to extrapolate your product’s ship date
  3. Compare the projected progress against the actual progress an the project progresses

See Warning Signs, below.

What Does it Look like?

You measure the number of user capabilities that work—work for users, for real, in production—not the number of hours that bottoms have been in seats; you measure results, not effort. Track the work intended to be in this timebox and the amount of work completed thus far.

Adjustments to the content or time frame of a release are made based on how much of the software is working, not how many hours are invested into it.


You don’t need any large or complicated tool to track feature completion; a simple spreadsheet and a chart on the wall are often all that is needed to track this information.

Ensure everyone knows what tasks need to be worked on. Deciding that should be a very quick and informal process, not a big high-ceremony affair.

Your spreadsheet has a section for each release and a line for each team. Each team’s feature allotment is listed, along with an estimated (or actual) number of the stories for each feature:

A representative from each team will report weekly on how many features have been completed.

When the rate of completed work is trending towards a date far beyond the desired ship date, reduce the scope of the release instead of trying to force more work from the teams. Team capacity is addressed in CapabilityPlanning, but treat capacity as a constant for the current release.

Warning Signs

  • Teams attempt to share status exclusively through a tool (even a simple spreadsheet). Use every practice as an excuse to have a high bandwidth conversation, and look someone in the eye, even if you update the tool during that meeting
  • Working, tested features require significant additional time and work before they’re ready to ship
  • The features included in the release are sufficiently nebulous to justify almost anything
  • Teams disagree about what a feature is or contains
  • Teams have significantly different “definitions of done”
  • Management is so upset with the projected end date that they turn off the reporting
  • Management is so sure the original dates should stand that mandatory overtime is required

Growth Path

Learn what your team’s capacity is by watching these numbers for several months. As you learn what they’re capable of delivering, you’ll learn how to plan realistic releases and how to more effectively direct your teams to get the product you want.

Understanding the problem is not under-performing delivery teams but unrealistic expectations is the first step to growth.

Create a challenging but sustainable work pace and you’ll discover predictable ship events, higher quality, and loyal team members.

Exercises to Get Better

Graph the data in different ways to understand which forms are best absorbed by yourself or others, as well as which format shines a light on your areas of concern. There are many ways to graph this information and different formats resonate differently with different people. Find the ones that work best in your organization. But again, focus on results, not efforts. We only ship working, tested features, not hours.

Try to anticipate what your teams will accomplish in a given timebox. Attend their demonstrations and see what’s working and what’s not. Get involved with your teams meetings.

Plan a release your teams believe they can hit comfortably instead of one that will tax (or overwhelm) them. Help the teams hit a few comfortable targets. It’ll give them confidence, as well as the space they need to get better in this new way of working, while also helping you improve your understanding of how they work.

Try to anticipate when a release will ship. Use the progress of the teams and their completion rates to anticipate completion. Remember that the past usually looks like the future, base your calculations on what the teams have been able to recently complete. Never assume a faster rate than you’ve seen in the past. That way lies madness. And ulcers.

How to Teach This Practice

Doing the math is often all that’s needed, but it must be visual. Many executives are data driven individuals. They’ll want the spreadsheet. Others need a graph. So provide both.

The numbers that matter are:

  • Features per release (what’s going into the next one)
  • How many features did these teams have over the last six months?
  • What’s the projected completion date for the next release based on this data. (Hint, it’s usually 2 to 3 times longer than anyone thinks it’ll be.)

Sometimes people get upset when they first see these numbers, but they’re almost always upset with themselves or their lack of awareness. We haven’t (yet) seen anyone upset at the person presenting the numbers.

How To Fail Spectacularly

  • Pretend that “coded” or “first pass” means “done” instead of “done” meaning working, tested features “ready to ship”
  • Eliminate this reporting and practice because you don’t like how far out the ship date is projected (hint: this is sure sign you instinctively know the numbers are correct, but you don’t want them to be.)
  • Shopping for a new tool, new process, or graph will generate or show the numbers you want to see (instead of the truth)

The silver bullet tool

Far too often an executive or manager will try to solve their problems tracking progress with a new tool or a major change to their existing tooling. This new tool is always costly, or the tooling update is driven by an expensive consultant. It’s important to realize that these changes will interrupt a team’s workflow. With the best of intentions, the change will slow everyone down. Resist the urge to chase the elusive silver bullet and instead embrace the simplicity of a spreadsheet.

First, understand what your teams are trying to do and how much is done. Then, when time permits, feel free to upgrade the tooling. But never embrace a tooling upgrade in the midst of a stressful project. These upgrades only benefit the tooling vendors and consultants, never the organization.

←Prev (Small Stable Teams)(Lead the Way) Next→

Follow @growsmethod on Twitter, or subscribe to our mailing list:

Sign up for more information on how you can participate and use the GROWS Method®. We will not use your email for any other purpose.