Skip to main content

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS
A lock ( ) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.

Share your experience with the FAS IT-Playbook by taking this brief survey

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

Agile Values & Principles Agile Team Member Roles Epics and Stories (Issue Types) Roadmaps, PIs, and Sprints Metrics Team Profiles Jira and Confluence Agile Resources

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 Gathering

You 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:

A funnel-shaped diagram showing the hierarchy of issues types within the FAS Jira Project template. At the top of the funnel is Initiative, which usually represents a high-level cross functional effort that captures the general strategy behind a large-scale project. The next level down is Capability, which captures solutions that may span multiple program increments. Below Capability is the Portfolio Epic, which focuses on delivering customer value and is made up of multiple epics. Below Portfolio Epic is the Epic, which is a smaller issue type that still focuses on value to the customer. The lowest level is the Story, which represents a small chunk of development work that the development team will work on during a sprint. Tasks and Bugs are also included on this level, and they may also be worked on by the development team.

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.

A bar graph depicting the most commonly used issue types within FAS-IT. The most common issue types are Epics and User Stories. The second most common are Portfolio Epics and Capabilities, followed by defects. The next most common after that are subtasks and risks. The least used issue type is Tests.

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:
  • Team refines Epic and Story sizing estimates. 
  • The RTE/SM will associate the PI Objectives with the relevant Epics.
During Program Epic Kanban:  team reviews Epics ready for implementation and assigns Epics to a Program Increment Note: Owner can refer to Product Manager/ Product Owner/ Epic Owner Enabler Epics are co-owned by System Architect/ Enterprise Architect/ Tech Lead
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:
  • Team adds stories (new work, DM&E, O&M, etc.)
  • Team removes/ updates/further articulates/decomposes Stories
  • PO prioritizes Stories
During Sprint Planning:  
  • Team discusses each story and its difficulty, size, complexity, uncertainty, technical challenges and acceptance criteria. The team then agrees to a size estimate using a hours-based pointing method whereby 1 point = 8 hours (or a day's worth) of work.
  • Team agrees which stories they will commit to completing within a Sprint.
During Sprint execution, the RTE changes the Story’s status in JIRA  (Ready for Approval, In Progress, Done).

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
  • User story is clear and well defined
  • User Story meetings INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable) Guidelines
  • User Story has well-defined Acceptance Criteria
  • User Story has been estimated by the team
  • User Story is achievable within a sprint
  • User Story dependencies have been identified
  • User Story is measurable and testable upon completion
  • Epic is ready when
    • Epic follows the appropriate format:
      • Name: Short phrase
      • Benefit statement: What is the benefit? Who benefits?
      • Acceptance Criteria: can include potential gates, audits or review required before acceptance
    • Product Manager/Owner is identified
    • Epic can fit in a Program Increment
    • Epic is estimate according to WSJF
    • Epic is prioritized by PM/PO and Epic Owner
    • Security Controls are marked
    • Epics is in the backlog (i.e., it has been approved and is awaiting implementation)
    Ready for Sprint Planning when
    • User stories targeted for the sprint are ready (i.e. meet DoR for a User Story)
    • Sprint backlog is prioritized
    • Team capacity for the Sprint is calculated
    • Sprint objectives/goals are defined
    Ready for PI Planning when
    • Epics targeted for the PI are ready (i.e., meet DoR for an Epic)
    • Reference PI Planning Checklist for details


    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
    • Stories satisfy Acceptance Criteria
    • Acceptance testing passed
    • Unit and component tests passed including:
      • Minimum 70% coverage
      • Static Code Analysis done
      • Code Peer Reviewed and conforms to program standards
      • Mock test and Stubs where applicable
      • Tests are automated unless required to be manual
    • Documentation is updated for services/APIs
    • Assets under version control
    • No must-fix defect
    • Story accepted by Product Owner
    • Verify using 508 Testing Process
    • Integration testing performed and artifacts uploaded to Confluence
    • Security scans and artifacts uploaded
    • Test code coverage uploaded to Confluence
    • Test results including 508 compliance uploaded to Confluence
    • Epic meets Acceptance Criteria
    • All stories for the Epic have been accepted including security Continuous
    • Delivery processes stories
    • System integration testing complete
    • Functional regression test complete
    • Epic demonstrated
    • No must-fix defect
    • Docuentation related to the Epic has been updated
    • Epic accepted by the Product Owner
    • SMART PI Objectives have been met Business Value calculated
    • All Epics for the releasable set are done and meet Acceptance Criteria
    • End-to-end testing done
    • Integration testing done
    • Performance testing done
    • Security review complete
    • Regression testing done
    • No must-fix defects
    • Collection of Epics included in build definition and deployment process
    • User, release, installation documentation complete
    • Documentation complete
    • Collection of Epics accepted by Product Manager
    • Business outcome has been met
    • Hypothesis Statement is true
    • Portfolio Epic accepted by the Portfolio Epic Owner
    • MVP tested
    • MVP in Production
    • Functionality has been demonstrated
    • Closeout complete

    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-IT

    Learn more about the FAS Jira Project Template (FJPT)