I touched earlier on the transparency of agile and I’ve been thinking about some of the ways that we track/report information in agile projects.

In all the projects I’ve been involved in the data being tracked almost exclusively referred to development time. One of the advantages of having continuous analysis/development/testing is that we are able to reduce the time spent on the System Integration and User Acceptance Testing phases of the project.

In a typical waterfall project most bugs would be found in these two stages of a project, and they would typically be fairly lengthy affairs.

The idea behind several of the agile practices is that the number of bugs/defects in the code base will be significantly lower than you would experience with a more traditional approach. Therefore the amount of time reserved SIT and UAT can be significantly reduced.

From what I’ve seen this is not always pointed out. It is almost like it is considered implicit in the fact that we are using an agile approach to software delivery and does not need to be explicitly stated.

I am now starting to believe that it does, and more than that - it should be actively pointed out as a benefit of using an agile approach.

We should be pointing out that 'Yes, it may take longer to produce the code than would be possible if we just coded it straight out with no testing but the total time from the first line of code being written until the time it’s production ready will be less'. We should also point out that the benefits of our approach will only increase as more code is written and the practices practiced come into their own.

I’m not sure what the best way of doing this would be - perhaps it could be something as simple as including estimates of how long SIT/UAT will take as part of a release plan and then including these on the burn up chart.

Or is there another tool available to do this?