GROWS logo

Progress Management

Great 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.

Pain Points

  • No management-level visibility into the team’s work or progress
  • Too many failed projects that looked viable until the last minute
  • Projects that consistently slash features at the last minute to meet dates
  • 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


✓ 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 timeboxed iterations.
  2. Ensure that release planning has occurred and work is contained in features (which contain stories)
  3. Track historical size of features and how many stories per feature TODO: Units?


  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 project’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 features 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 release 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 is often all that is needed to track this information.

Ensure everyone knows what features are going into a release. This information is usually decided in a release planning meeting (or similar practice), but can change over time. Excessive change here is dangerous, so be careful.

Your spreadsheet has a section for each release and a line for each team. Each team’s feature commitment 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 CapacityPlanning, 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
  • Completed software requires significant additional time and work before it’s 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 can only ship working software, not hours.

Try to anticipate what your teams will accomplish in a given iteration. Attend their demonstrations and see what’s working and what’s not. Get involved with your teams iteration ceremonies. Challenge your teams to hit 100% of their iteration commitments.

Plan a release you believe your teams 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, so use traditional story per feature ratios and stories per iteration to do your calculations. 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 stories per feature did these teams have over the last six months?
  • How many stories per iteration were completed 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 “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, never the organization.

←Prev (30m Thinking Appointment)(Checklist for Executives (Stage 1)) 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.