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