| Acceptance Criteria |
Attributes to validate a story meets the users’ expectations. Expressed in clear, simple, and actionable language that can be translated to test criteria. |
| Backlog |
A dynamic list of prioritized user stories. Backlogs can be managed for the overall program, each product, and each sprint. The Product Owner, working with stakeholders, will regularly groom the backlogs to ensure the work is clearly defined, in priority order, and with reasonable estimates. The higher priority work will have the greatest details defined and completed first, whereas work planned for future releases will be lower on the backlogs with less fidelity. |
| Burndown Chart |
A common metric in Agile to show the amount of work remaining vs time. It is used to assess the progress of the development team in a sprint. |
| Continuous Deployment |
Seeks to deploy new code as quickly as possible by automating integration, testing, and deployment to production. |
| Continuous Integration |
Merging software changes into a shared code repository several times a day. This method reduces the time and risks to deploy new software. |
| Definition of Done |
A shared understanding of what it takes to meet users’ expectations typically for a user story. |
| Development Team |
The cross-functional team typically composed of contractor staff: software developers, including software and security engineers, data specialists, testers, quality assurance, and configuration managers. |
| Epic |
A large body of work to be completed during development; typically, too large to complete within a sprint; is further decomposed into smaller features and user stories. These may express business functionality or identify constraints placed on the product or system. Epics are used in planning and cost estimation. |
| Extreme Programming (XP) |
An agile software development methodology with frequent releases and checkpoints with short development cycles. It seeks to produce higher quality software and reduce the cost of changes. |
| Iteration |
A timebox to develop and deploy software. AiDA uses the terms releases and sprints as notional iterations. Each program will identify a common iteration length. |
| Kanban |
A method to visualize the work of the development team in multiple columns to assess the progress and identify any bottlenecks. Kanban boards may be on white boards, poster boards with Post-It notes, or software tools for team collaboration. |
| Minimum Viable Product (MVP) |
The version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. (Source: Eric Reis) |
| Pair programming |
When two programmers develop and test software via a single workstation. As one writes code, the other observes and they switch roles frequently. This allows faster learning, drives collaboration, and ideally improved software quality. |
| Planning Poker |
A method for a development team to estimate the size or amount of work required for each story. Each team member individually lays down a card for their estimate. The team will discrepancies to reach a common understanding of the planned work. |
| Product Owner |
The authoritative user community representative who manages the backlog(s) and requirements prioritization, communicates operational concepts to the development team, and provides continual feedback to the development team on their products. See analyze requirements for additional details on this role. The Product Owner is frequently a government employee from the user organization that owns the requirements, but some programs have a contractor fill this role and then work with government users. |
| Release |
The release represents the core element of the program structure, guiding how frequently the program delivers capabilities to the end users. The length of each release depends upon operational, acquisition, and technical factors that should be discussed with stakeholders across the user and acquisition organizations. As a general guideline, most releases should take less than six months (as championed by US CIO, GAO, and FITARA). Shorter release cycles have several benefits, the most important being that the program deploys useful capability to the end-user faster. |
| Scrum |
A collaborative Agile development framework for managing projects; features iterative design, development, and frequent deployment of functionality. Includes direct interaction with end-users and other stakeholders, and enables and empowers self-organizing teams. Usually involves a close communication process that includes brief, daily status meetings. |
| Scrum Master |
This person establishes and facilitates the daily Scrum, the Scrum of Scrums, and other Agile ceremonies throughout development. This is typically a member of a contractor team, depending on the details of the individual contract. |
| Scrum of Scrums |
The methodology to scale Agile development whereby multiple scrum teams work together to deliver a solution. |
| Software Factory |
Low-cost, cloud-based computing used to assemble a set of tools enabling developers, users, and management to work together on a daily tempo. (See Software Factory page) |
| Sprint |
A short cycle of work (usually two to four weeks in duration) that focuses on completing a defined subset of project deliverables, or usable functionality. Each sprint includes planning, design, development, integration, testing, and demonstrating working software to the product owner, users, and other stakeholders. |
| Story Point |
The unit of measure to determine the size or amount of work required by a development team to complete a story. Story points are unique to each development team. A story point of 1 is the smallest unit and all other work is assessed relative to that size. |
| Technical Debt |
Rework that needs to be done by the development team as an easier, short-term solution was pursued, yet further changes are needed for improved rigor and subsequent developments. |
| Test-Driven Development (TDD) |
A software development methodology where requirements are translated into test scripts. The software is then developed and improved upon until it passes the test. |
| Users |
Those who will ultimately use the software solution. Users convey operational concepts and requirements/needs, participate in continuous testing activities, and provide feedback on developed capabilities. It is critical for the development team to have a clear understanding who the end-users are, to ensure they are focused on delighting them. A core Agile tenet is active user involvement throughout development. |
| User Story |
The smallest unit of requirements written from a user’s perspective of how they will use the software. User stories will be defined and prioritized by the Product Owner via backlogs. User stories that cannot be completed within a single sprint should be divided into smaller elements. Each user story should have clear acceptance criteria. |
| Velocity |
The number of story points a development team completed during an iteration (release/sprint). A team’s velocity over multiple iterations is a key metric to track a team’s performance and aids planning and scheduling future work. |
