When I coach managers or leads, one of the most frequent questions I hear is: "How do I know I'm making progress?" Typically, the manager or lead is working on a long project or a long initiative, such as transitioning to agile, and it can be difficult to know if you are making progress or spinning your wheels.

Plan in Small Chunks
No matter what project you are working on, plan in small chunks. Sure, keep the vision of the end product in mind, but know that you can only do so much in a given time period and plan what you can do for the short term.

One way to do this is with rolling-wave planning. As an example, suppose you want to plan a large Web application release. You would note your major milestones, such as "UI walkthrough for shopping interface," "financial integration with financials package," or "limited release to trusted users," in addition to "release for general public." Now, take the first milestone and ask yourself and the project team, what do we need to do—in detail—to get to that milestone?

I like making rolling-wave plans on sticky notes on the wall, not in Gantt charts. I ask people to plan in inch-pebbles—one- or two-day tasks that are either done or not done. With inch pebbles, people see the details of what they have to do, and it's easier to see if anyone has trouble with a task.

With inch-pebble sticky notes, if anyone on the project team sees a problem and needs to change something quickly, it's obvious what the effects are. They can ask the people affected to work with them on the change.

If you're agile, you already do something like this when you take a number of items off the product backlog and commit to completing them inside an iteration. The difference is that an iteration is timeboxed, and your rolling-wave plan doesn't have to be.

If you want to optimize your rolling-wave plan, ask the team to plan in small chunks inside a timebox. "How much of this can we accomplish in the next two weeks?" That helps people reduce the size of their work items and focus on what "done" means for that milestone.

When you get to the end of a timebox, you can see your progress-even if you're not using agile iterations, because you have met a milestone on your rolling-wave plan. Once you finish one wave of work, you plan the next. If you're like me, you start planning the next wave before you've finished this one—hence, the "rolling wave." I normally have three to four weeks of detailed inch pebbles, so everyone on the team knows where we are and what's next. We plan only a week's worth every week. Replanning is quick and easy, because we're not planning a lot at any one time.

Finish Small Chunks
Once you start planning in small chunks and replanning frequently, you realize that you need to finish small chunks, so your replanning makes sense.

One of the problems of a lot of work in process is that you are not completing work and making progress on the project. For example, if you're working on "UI walkthrough for shopping interface" you don't want to start work on "financial integration with financials package" until the UI walkthrough work is done.

When you ask people to complete just one task or a series of related tasks for one major milestone, everyone focuses on that one milestone. When people pay attention to just one feature or feature area, they are likely to complete work faster or know what's preventing them from completing the work.

The problem is that work in progress is not a measure of completion. If you're halfway through a project and have everything half-started, are you half done? You can't tell. But, if you're halfway through a project and have half the deliverables completed, are you half done? You could be half done—maybe a little more or less—but you know with certainty how long it took you complete this work.

The more work in progress you have, the more it feels as if you are spinning your wheels. Measure Progress
It's really difficult to know how long a project will take, because projects are full of work we've never done before. So, we guess at the estimates—a reasonable thing to do.

But, what if you could gather data from your estimates about your completed work and use that to measure progress and look forward? When you keep a rolling-wave plan and use inch pebbles to break the work down, you have a small enough effort to return to the original estimate and say, "Well, we thought this would take us a couple of days. It took three days. Do we have more tasks like this in our wave? Maybe we want to make them three days." Or, if you get lucky, maybe your work takes less time.

If you and your team always underestimate, try breaking the tasks down into smaller chunks, so you can see where the time goes. Instead of defining two- or three-day tasks, break work down into half-day or one-day tasks. That will make your schedule more accurate for this project and make it easier to see where you are spinning your wheels.

One of my clients realized that developers spent hours every day waiting for their builds to complete. Originally, everyone just accepted this problem as "the way things work here." But, when they chunked down their tasks and self-imposed pressure to complete work, they realized they no longer were willing to accept the long build time. In the time it took them to deliver one feature, they also reworked the build system so that they eliminated the circularities and made the build much faster. Now, they could finish features faster and with less aggravation.

Measuring your estimates against actuals only works on completed work. You can try to measure this on development or testing alone, but, until the whole feature works, you won't know how much more development or testing you will need to do and, therefore, whether your measurement is accurate.

Check Yourself
If you're wondering if you are making progress or spinning your wheels, check how your project is organized: Are you planning in small chunks and completing work? Are you measuring how long it took you to finish work?

You'll start making progress before you know it.