Epics and Stories (Issue Types)
Learn more about how the Agile process has evolved across time at FAS-IT including the issue types commonly used among the divisions.
Agile Topics & Concepts
Standardized Issue Types at FAS
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. For more detailed information on how to gather and break down requirements, visit the Requirements Gathering page.
Requirements GatheringYou will find that when working with FAS-IT, we generally work with these Agile issue types, which are standardized fields in the FAS JIRA Project Template (FJPT). Not all projects utilize all fields, but these issue types are some of the most commonly used:

Issue Types That FAS-IT Initiatives Use
In Agile methodology, enterprises define a hierarchy of issues. At FAS-IT, issue hierarchies and issue types vary slightly (and are defined) by each individual initiative i.e. ASSIST, ACR, FCP, CALM, DX, Data Architecture, FSS-19 modernization, Fleet, MAS, PPMS, TAMS, TMSS.
Each initiative has a slightly varying issue hierarchy that works best for them. The broadest issue types may include Initiative (as an issue) or Portfolio Epics, and/or Capabilities. All use Epics and Stories.
The FAS JIRA template is used by all, flexible and can accommodate the various issue hierarchies within each initiatives.

How Issue Types Map to PI and Sprint Planning
During PI and sprint planning, each of the issue types help the team understand how the day-to-day work ties back to the strategic vision and business objectives of the project. More details are provided below on how each issue type is used in these planning sessions.
Method | Related Actions During Ceremonies |
---|---|
Theme e.g. Strategic Vision | Theme usually refers to the overarching objective of a system modernization or group of system modernizations. Other than linking lower level issue types back to initiatives and themes, there is usually minimal discussion of initiatives and themes during the Agile ceremonies. |
Initiative e.g. GSAFleet.gov | Initiative usually refers to the name of the system or suite of systems that is being modernized (ex: GSAFleet.gov, Acquisition Functions). Other than linking lower level issue types back to initiatives and themes, there is usually minimal discussion of initiatives and themes during the Agile ceremonies. |
FAS Portfolio Epics | Identified and added in FAS Portfolio Epic Kanban Funnel (EBCs, ELR, DM&E, O&M) |
Capabilities | Capabilities are relatively new to the Issue Type hierarchy used at FAS and can span a single PI or multiple PIs. They may be discussed / refined at a high level as part of the PI planning. |
Features | Features are issue types that are not used in the FAS-IT standard hierarchy, although some Programs use them. Instead, Program Epics are realized directly by Stories. |
Epics / Program Epics May be business epics or enabler epics |
Identified and added in Program Epic Kanban Funnel (EBCs, ELR, DM&E)
During PI Planning:
|
User Stories Each has Acceptance Criteria |
During PI Planning team refines Epic and Story sizing estimates
During Backlog Refinement meeting so ready for future Sprints:
|
Full List of FAS-IT Issue Types from FAS Jira Project Template
FAS Portfolio
- Theme - GSA/FAS Strategic Themes
- Initiative - Aligned to Portfolios and/or Value Streams - links to Theme
- Portfolio Epic - Aligned with the investments by Portfolio/Value Stream - links to Initiative
FAS Programs – Solution and Agile Release Trains, Teams, etc.
- Portfolio Epic - Aligned with the investments by Portfolio/Value Stream - links to Initiative
- Capability - Solutions that may span multiple Program Increments (PIs) - links to Portfolio Epic
- Epic -Epics/Features to be completed within a Program Increment (PI) - links to Portfolio Epic/Capability
- Story -Work to be completed within the sprint - links to Epic
- Sub-Task -Tasks aligned to Stories with assignments - links to Story
- Risk - May be created at all levels and visible on project Risk board - may link to any issue
- Defect - Reported problems and/or bugs - links to Epic/Story
- Test - Plans and/or test configuration connector
Developing Criteria
The sections below cover how to write good acceptance criteria and definitions of done for stories.

Definition of Ready
The Definition of Ready (DoR) is a crucial concept in Agile software development that outlines the specific criteria a user story or backlog item must meet before it can be considered ready to be worked on by the development team. It ensures that all necessary information, dependencies, and resources are in place, allowing the team to start work without unnecessary delays or interruptions. The importance of DoR lies in its ability to enhance productivity, minimize misunderstandings, and streamline workflow by ensuring that tasks are well-prepared and actionable. For example, in an Agile software development organization, a user story might be considered ready if it includes a clear description, acceptance criteria, necessary design mockups, identified dependencies, and any required approvals. This means that the development team can confidently pick up the story during a sprint planning meeting, knowing they have all the information needed to deliver a valuable increment of software within the defined sprint time-box.
Definition of Ready from the FAS-IT Confluence Community of Practice:
Issue Type | Definition of Ready |
---|---|
User Story is ready when |
|
Epic is ready when |
|
Ready for Sprint Planning when |
|
Ready for PI Planning when |
|

Acceptance Criteria
Acceptance criteria are specific to a particular user story, detailed, focusing on functionality and requirements meeting user needs. They must be met in order for a story to be considered ‘done.’
Examples of Acceptance Criteria for a Story
- 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

Definition of Done
The Definition of Done is an agreed-upon set of requirements that must be completed before a task (e.g. user story) can be considered complete. However, the DoD applies universally to all the user stories, other backlog items, or tasks. The DoD ensures that quality and completeness meet consistent standards across all the pieces of work. The DoD serves as an official “gate” separating things from being “in progress” to “done.”
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
Definition of Done from the FAS-IT Confluence Community of Practice
User Story | Sprint/Iteration | Epic | Sprint/Iteration | Portfolio Epic |
---|---|---|---|---|
|
|
|
|
|

FAS Jira Project Template
Issues are documented in the corresponding fields of the FAS-IT JIRA Project Template (FJPT). The materials linked below will help you know how to best leverage the FJPT.
Learn more about Jira and Confluence at FAS-ITLearn more about the FAS Jira Project Template (FJPT)