Story Creation

POs, as well as our Principal Engineers, and other engineering leadership (Michael R, Ryan L, etc.), are responsible for passing down new requirements, features, changes in scope, etc. of existing and new components.

POs are not in many (if any) VA level meetings, and therefore can’t take 100% responsibility for all new story work for their components. There is some reliance on engineering leadership above POs to provide guidance on what should be worked within a given component.

With that said, POs are responsible for creating stories for their component to provide the necessary functionality within the scope of requirements. POs need to ensure that the stories are fleshed out with robust descriptions and acceptance criteria.

Issue Types

Bug

An unexpected outcome or error that has been identified.

Epic

Larger grouping of stories. These are too big to be 1 story, so are broken into multiple, smaller stories that are completed across several sprints.

Story

Larger code changes, changes to important deployment features, changes to Swagger document. Note a story may require updating SRVDD if endpoints change or are added.

Task

Research, documentation, or other work that does not affect code.

Technical Debt

Minor code changes, version updates, things that do not affect the Swagger.

If a release includes stories, then it must be a major or minor version change. Patches cannot include stories. Only tech debt and tasks can be included in a patch.

Story Creation Best Practices

The story description and acceptance criteria are extremely important. They help clarify the expected outcome for the developer that works on the story.

When creating a new story, keep these in mind:

  • User story description

    • As a <type of user> I want < goal> so that <reason>

    • Example: As a maintainer of privacy-policy-viewer, I want the web site used to view policies to be kept up to date with the latest U.S. Web Design System so that the site is accessible and kept up to date.

  • The description of a user story should be clear and concise.

  • Includes notes and attachments where appropriate.

  • Acceptance Criteria

    • Clarify the expected outcome(s) of a user story in a concrete manner.

    • Include version number within the AC (CKM)

    • Example: CKM-30049

      • For the MPI searches initiated from the Mobile MVI Service "/traits/mvi/identifiers" and "/traits/mvi/persons" endpoints:

        • The "initialQuantity" value that is sent to MPI in search requests is configurable

        • The "initialQuantity" value that is sent to MPI in search requests defaults to "1"

        • The swagger and SRVDD documentation for these two endpoints is updated to state that they perform Unattended MPI searches that result in a response containing the single highest probable match, if a match is found.

      • Integration and/or unit tests verify that MPI search requests are made with an "initialQuantity" value of "1"

      • This change will go into version 1.35