James Shore

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

Inside the Book

• 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