Status Reporting

A report of physical contents usually includes version label names and a manifest (or packing list) of all the files in the released build. In addition, a file name and revision ID is often maintained in each source-file. This enables (with help from the version control tool) reporting of a bill-of-materials (BOM) listing all the source-file names and revision numbers that were used to build the target executables and libraries.

A report of functional content usually includes all the features/ requests that were implemented for an iteration. Each developed feature is typically associated with one or more tests that verify its proper implementation (for development) and functionality (for customer acceptance). Once again, simplicity is preferred in tracking tests to features: each functional test is associated with a named feature in a spreadsheet or simple tracking database, or on index cards (perhaps even on the back-side of corresponding story-card). Sometimes the functional test is expressed exclusively in the source code (and comments) that exercises functionality under test. Tests are automated to the greatest extent possible and stored as a regression test-suite that is run after every build. Testing results/status are usually reported with each delivered version of the software.

Some agile teams use a spreadsheet to track feature-lists and backlogs, or a simple database to track the requests. Some teams use simple out-of-the-box request/defect tracking systems or open source systems, the most popular of which at this time are Bugzilla, GNATs, and Jitterbug. In either case, the tracking system (or mechanism) can easily be used to sort and report requests by date, priority, estimate, and target iteration/release. These systems enable the agile team to report the status of implemented, and to-be-implemented, functional requests for any iteration.