Requirements & Criteria
Clearly structuring and defining both the scope of the work and appropriate acceptance criteria drives better delivery in Agile projects.
Agile Topics & Concepts
Issue Hierarchy
In an Agile environment, the work is typically broken down into an issue hierarchy like the one shown below. This helps translate the work into consumable pieces that can inform the daily work and tie all of the work back to the broader goals of the initiative.
The following resources can help those implementing Agile practices to effectively break down work for their team.
Managing Risks
The sections below cover key aspects of risk management within Agile projects. For additional resources on risk management, visit the links below from the recent Agile in Action session facilitated by the FAS Agile Community of Practice:
There are primarily 3 levels of risks that could impact a project:
- Portfolio Level: An uncertain event or condition that could prevent the portfolio from meeting its objectives
- Program Level: An uncertain event or condition that has a potential impact to a program goal
- Team Level: An uncertain event or condition that, if it occurs, has an effect on at least one team objective
Within Agile, there are five fundamental phases in the risk management process. The first phase is Identifying risks, which includes determining which functions have the greatest impact on the program, what interruptions may occur, and their associated risks. In the Categorizing phase, risks are broken into categories including strategic, operational, compliance, security, etc. In the Analyzing phase, the probability, impact, tolerance threshold, and prioritization of the risks are determined. In the Responding phase, owners are assigned to each risk and roles are assigned for management, monitoring, and resolution of the risk. Lastly, in the Monitoring and Controlling phase, the team identifies new risks and plans for them, and updates plans for existing risks as needed.
Developing Criteria
The sections below cover how to write good acceptance criteria and definitions of done for stories.
Acceptance criteria are the primary development artifacts that detail the ‘what.’ They must be met in order for a story to be considered ‘done.’
Examples of Acceptance Criteria
- User can only submit a form by filling in all required fields
- Submission of the same IP can only be made three times within 30 minutes
- User will receive a notification email after successful registration
How to Write Good Acceptance Criteria (AC) For well understood, and high quality AC:
What Is Definition of Done?
The Definition of Done is an agreed-upon set of requirements that must be completed before a project or user story can be considered complete. It is applied consistently and serves as an official gate separating things from being “in progress” to “done.” Some examples of Definition of Done are shown below.
Examples of Definition of Done
- X% of code coverage from unit tests
- Automated tests for stories have been created and passed
- Acceptance Criteria is met
- Security scans are complete and show no critical vulnerabilities
Outcomes are the desired results or impacts that a project or a specific piece of work aims to achieve. They are broader than deliverables and focus on the value created for the end-users or the organization. Outcomes are considered during the definition of epics and user stories. They guide the team's efforts toward delivering meaningful value and help stakeholders understand the broader impact of the work being done.
Estimates represent the team's assessment of the effort required to complete a task, user story, or epic. Estimation helps in planning and prioritizing work effectively. Estimates are an essential part of sprint planning. Teams assign estimates to user stories or tasks, which aids in capacity planning and ensures that the team commits to a realistic amount of work for the upcoming sprint.
