Measure success based on iterative outcomes, not project milestones

Value shouldn’t come at the end of a project — it must be provided to end users within no more than six months of the contract being awarded, and constantly from there on out. At the end of the first sprint, working code must be delivered to the agency for its review, and that must continue with every subsequent sprint. End users should evaluate work at the end of each sprint, regardless of whether the work has yet been deployed for daily use.

Don’t measure progress in "story points," lines of code written, person-hours of work, etc. The only measure of success that matters is what value has been delivered to end users. This is best assessed by attending semi-weekly sprint reviews and talking to both the scrum master and the government product owner.


  • [ ] The vendor team will use agile
  • [ ] The vendor will be required to deploy functioning software into a government-owned environment at the end of each sprint
  • [ ] The project team will interview and test their work with end users routinely, both to inform planned work and to determine whether the work already done is correct
  • [ ] The RFP will have no mention of a detailed project schedule, and there will be no mention of Gantt charts or Independent Validation and Verification (IV&V) contracts
  • [ ] A legislative staffer will be assigned to provide oversight of the project, and will coordinate with project leadership to monitor progress by periodically attending sprint reviews

Key questions

  • Can the requesting agency deliver value to end users within six months? What, specifically, is that value?
  • Is the agency prepared for the vendor to continuously interview and test their work with actual end users of the software — perhaps including agency employees?