Skip to Main Content

Foundational Agile Practices

  • Engaged Product Owner – Each team has a distinct individual representing the business who is closely involved and who has the authority to make timely decisions regarding user story development, prioritization, and acceptance.
  • Near-Term Requirements are Small and Testable – Near-term requirements for the team will be testable and small enough to be completed within the defined time box. Many requirements formats are compatible (e.g., User Stories), as long as they are small, independent, and testable.
  • Test Early and Often – Teams write test cases up front as development gets started. Conversations about how code will be tested result in clearer requirements, decreasing late findings and improving alignment of the analysts, developers, and testers. Teams execute test early and often — as frequently as possible. Defects and technical debt are reduced through a definition of ‘Done’ that focuses on delivery of quality, defect-free code.
  • Unit Testing – The development team creates, maintains, and runs detailed tests that verify individual units of code against established acceptance criteria. Establishing clear acceptance criteria and building them into development as unit tests enhances code quality and reduces rework.
  • Definitions of Done – Teams come to agreement with stakeholders on what it means to be 'Done' with a requirement/story, 'Done' within a time box, 'Done' within a release, and ‘Done’ with overall delivery.
  • Time-boxed Iterations – Teams adopt a fixed-length iteration or time box that is no more than four weeks and no less than one week, with a preference to two weeks. This iteration or time box will be the standard cadence for planning, completing, and demonstrating working and tested functionality. The time box is over when the time has elapsed, not when the planned functionality is completed.
  • Iteration Reviews – Teams conduct reviews at the end of each iteration to demonstrate functionality and to solicit feedback from the stakeholders about what has been delivered and what is planned to be delivered in the next iteration.
  • Velocity Tracking and Estimation – Each team measures the velocity of their own iteration and uses that information, in conjunction with estimation techniques, to develop predictable plans for future iterations and releases.
  • Incremental Release Planning – Each team conducts regular release planning exercises culminating in agreed-to release plans/goals. The release plan supports the early and frequent delivery of functionality wherever possible.
  • Transparency – Teams make a wide array of plans, actuals, and other data continually and easily available to all stakeholders.