A look back at the best from a year ago.
How good are our estimates?
We can use PERT to estimate the time it will take to implement each requirement. We can use timeboxes to schedule the requirements within each release. If we don’t know how good our estimates are, its an exercise in futility. Scheduling is about more than predicting the future, its about knowing how much faith to have in our predictions.
Most teams think about testing in terms of code coverage – what % of the lines of code are covered? What matters to our stakeholders is how well the software works. More precisely, how well does the software let the users work? We should be targeting our quality message in relevant terms, because users care about what they can do with software, not how well we programmed it.
The problem is that we tend to think about our software from the inside out, and our customers think about it from the outside in. We need a way to communicate our understanding of the insides within the customer’s framework of understanding the outside.
We’ve posted tips about targeted communication – tailoring the message for the audience. Anthony Mersino has an excellent post from January of this year about how to write a good status report. He provides seven excellent guidelines for status reporting, and all of them around providing the message our audience cares about, as effectively as possible.