Are you asked for your progress during product development?
There are a number of ways you can answer this question. The most common one is where you inform your stakeholders by reporting the number of requirements you have built.
I would like to propose a different approach. One where you show progress towards how close you are to the intended goal.
Let me explain.
Ticking off a list
If you’re tracking progress by looking at the requirements implemented, you might be missing the point.
By implementing requirements, you certainly are making progress and perhaps your stakeholders are satisfied when they see your progress report. But the number of implemented requirements doesn’t say anything about achieving your business objective
for which your product is being built.
| “Can you please give me the status of your work? I want to measure the overall progress of the project” “What percentage of the requirements have you implemented?” |
Using numbers of implemented requirements to measure progress is pretty much pointless in the modern development era. Implementing a list of requirements doesn’t make your product successful.
Example of progress information when ticking of a list of requirements
Can burn-down charts help?
Burn-down charts are useless when you’re goal oriented. Burn-down charts show you the progress of backlog items within a sprint. Which can be used in certain situations, but certainly not when you’re interested in the goals or value.
Value
What if you use figures about the goal you’ve agreed with business stakeholders?
They would probably be happier.
If you pursue your vision and focus on achieving the intended goal, there is a big chance your outcome will be more successful.
There are many reasons for this. I’ll give you a few.
- After every iteration there is an opportunity to inspect the outcome, which gives you the ability to pivot or persevere.
- The increment is valuable. The customer notices instant value.
- By having a clear vision and intended goal, the involved team members are probably more motivated and inspired. This results in a better product.
- There is even a chance of finishing earlier than when you focus on implementing a list of requirements.
- Ordering the backlog makes more sense and is perfectly aligned with achieving the intended goal.
- Delivered features can be directly measured by looking at the outcome and value. The hypothesis of this feature is pretty easy to evaluate like this.
Metrics
By using a goal-oriented progress indicator, you force yourself to look at the numbers that make sense. I personally try to have a metric about the goal in the very first sprint. This is one of the first backlog items I write. And by having a visible dashboard that includes this essential metric, the team and stakeholders are seeing these transparent numbers on a daily basis.
While you’re at it, add the product vision and strategy as well. The combination of the long-term vision, mid-term strategy and current figures is the perfect setting for a team room or location to have your Reviews.
Concluding
If you truly want to deliver value for your customers and users, and you’re asked for progress information, it’s best to use numbers of the intended goal. Have these numbers readily available, preferably on your (easy to access) dashboard.
Example of a fictional dashboard with the vision and two main goals
