The Art of Agile Development: Reporting

June 10, 2008

Book cover for “The Art of Agile Development, Second Edition” by James Shore. Published by O'Reilly. The cover artwork shows a water glass containing a small sapling. The sapling has small green leaves. There is a goldfish in the glass.

The second edition is now available! The Art of Agile Development has been completely revised and updated with all new material. Visit the Second Edition page for more information, or buy it on Amazon.

in 99 words

A vision statement, weekly product demos, release and iteration plans, and a burn-up chart are a normal byproduct of your work. Share them as a matter of course.

Other reports take extra time. They're technically waste, but may be necessary to help build trust in your team. Roadmap and status emails summarize your release plan and demos. Productivity, throughput, and defect reports help management understand your effectiveness. Time usage reports help explain your velocity.

Avoid reporting lines of code, numbers of stories, and velocity. They're misleading at best. Avoid sharing code quality metrics, too: they require expert interpretation.

Commentary

Work in Progress

Section Outline

  • Reporting
  • Types of Reports
  • Progress Reports to Provide
    • Vision statement
    • Weekly demo
    • Release and iteration plans
    • Burn-up chart
  • Progress Reports to Consider
    • Roadmap
    • Status email
  • Management Reports to Consider
    • Productivity
    • Throughput
    • Defects
    • Time usage
  • Reports to Avoid
    • Source lines of code (SLOC) and function points
    • Number of stories
    • Velocity
    • Code quality
  • Questions
    • What do you mean, "Progress reports are for stakeholder trust"? Shouldn't we also report when we need help with something?
    • What if some of our stakeholders want to micromanage us?
    • Isn't this just busywork? We have an informative workspace, stand-up meetings, and iteration demos. Stakeholders and managers can visit any time. Why do they need reports?
    • What if programmers don't want to track their time for the time usage report? They say they have better things to do.
    • Why should the project manager do all the grunt work for the reports? Shouldn't he delegate that work?
    • Our organization measures employees individually based on the contents of certain reports. What do we do?
  • Results
  • Contraindications
  • Alternatives

Full Text

This chapter isn't online, but you can buy the book.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.