Our backend is already tracking everything… or close to it. And that’s it all comes down to in the end: Tracking. You can’t measure what you can’t track and you can’t improve what you can’t measure.
While doing the specs for a Project Report Card, we came across 4 factors that made sense in order to create a proper report card.
Velocity is an indicator how much effort is accomplished over a set period of time. This is estimated by trending the effort completed in the past. In order to have significant data, the team’s composition and sprint duration must remain the same.
Once estimated, you can use velocity to plan and forecast project completion dates and ajust the resources needed to complete it, if you are on a deadline. Let’s face it… aren’t we all?
Typically, you want your velocity relatively stable, but slightly accelerating. This is an cue that the team is getting more comfortable with the project and that progress is going well.
For obvious reasons, Quality is a key indicator of success for a project. You usually want to know the number of live defects that you have, and the number of “bugs reported vs bugs fixed”. This is will tell you the health of your project.
Then you want to know the percentage of stories that get rejected by the client or Product owner at the end of a sprint. You’ll want to keep that as low as possible, since it will be a major driver over the velocity of your team.
Reliability is an indicator of Planning quality and your teams capacity to be self-organizing.
For example, you’ll want to verify the amount of Committed Story points vs the Delivered story points. You’ll quickly see a trend between what the team believes it can deliver and what it can actually do – usually less.
Similarly – and this is especially true for those who do not use Story points – you’ll want to know your estimation accuracy : “time estimated vs time logged” for a task. This is great data since many projects and tasks have a lot in common, if you figure out that you systematically underestimate certain tasks by 20%, you can correct that have have a better forecast on your delivery dates. It’s called managing expectations…
Finally value. This is a great asset to promote Agile since it’s a common (mis)belief that Agile doesn’t speak to managers or high level execs.
By estimating the amount of effort needed to complete certain tasks or stories, you can do cost-benefit analysis and figure out which items give you (and your client) the best value for your sweat. There’s often a point in a well-managed project where the remaining value of the project to be delivered is not worth the effort needed to produce it. This is your cue to stop the project… optimal value has been delivered. Talk to your client first…
For internal evaluation, it’s also great to figure out the “cost of disruption”, meaning the cost of repairing bugs or managing impediments. This becomes an awareness tool and can be used to add (or remove) resources into testing, once we know whether this is an area where we can save or not.
Taking all of these into account, Planbox is currently building a pondered Report Card to give Planners a simple Progress report on their Projects. If you guys have any feedback, tips or pointers, feel free to chime in… before it’s too late. (hint: it never is)Alexandre