Agile

This document provides an overview of how MyUSA uses an agile design and development process for delivery. It discusses how we use GitHub as a tool to facilitate agile and provide transparency into MyUSA.

Objectives

The specific agile process we use here is designed to meet the following objectives:

• Issues can be prioritized and the priority is known to team members
• Team members quickly know what the next issues are to work on and can pick them up
• Automatic process tracking of issues, sprints, and workflow (minimize manual and offline product management)
• Be transparent in the development of MyUSA features, bugs, and roadmap

Agile

We'll leave the details of how we do agile to the forthcoming 18F Playbook. Instead, the focus of this document is applying those principles to MyUSA.

Development is broken down into sprints. Sprints are short, bursty development periods that create an artificial sense of urgency to constantly deliver. Sprints are managed through the use of GitHub milestones. Each milestone is a container that includes the issues being addressed in that sprint. During spring planning meetings, we'll decide which stories to put in the sprint milestone.

For the sake of this document, the term issue can mean a user story, a bug, a task, or any other work that needs to be done.

Workflow

Issues pass through the following workflow. This is merely a guide; not all issues must hit every step.

A new issue can be proposed by a member of the team or the public. The product lead then assigns labels to the issue to identify where it belongs and what it needs -- what stage of the workflow, what priority it has, what type of issue it is (eg, story or bug), and whether it is ready to be worked on or part of the backlog/icebox.

Issues are classified into one of the following needs:

1. Discovery -- Exploration of the problem space, ideation, and exploring solution feasibility
2. Research -- Conducting users needs studies and user research
3. Design -- Drafting solutions, architecture, creative materials, and specifications
4. Development (or Dev) -- Implementation of the design
5. Pull Request (or PR) -- The implementation is underway and ready for feedback. Note that implementations need not be complete to PR; the PR can be used to revise and get feedback on an in-progress implementation
6. Acceptance (or Accept) -- The PR has been accepted and the original issue can be accepted by another team member that verifies the functionality

When an issue needs content -- possibly for research, design, or development -- please add the needs content label.

Story Acceptance

Stories should be accepted by the product owner (in the case of user stories) or another team member or original requestor (in the case of tasks).

Stories must be marked as waiting for Acceptance with the accept label. The accepting person should:

1. Assign the story to themselves
2. Accept or reject
3. Always comment on the story's state, tag contributors, or 👍 reviewed and accepted stories
4. Apply the resulting labels (if reject) or close the issue (if accept)

Pull Requests

The norm is a 1 story = 1 pull request. Only in exceptional cases should you put more than one story into a pull requests.

Pull requests may be started before code is complete, in order to faciliate a discussion. Please mark that the pull request is in development and not yet ready by using the devel label.

Pull requests must be code-reviewed by another member of the team. Note that you cannot accept your own pull requests. If a request is ready for review, please use the accept label.

Final approval and integration of a pull request should be completed after both performing a code reviewing and verifying that the functionality matches the description and/or relevant stories/issues. The code should also pass all unit and integration tests, often automated with CI.

Contributions must follow our contribution guidelines, including using the git-flow model for naming contribution branches. We name our branches feature/foo, hotfix/bar, and task/baz.

Prioritization

We use the P# method of prioritization where P0 is the most important issue and P3 is of lowest importance. The priorities can generally be thought of as follows:

• P0 -- Any issue marked P0 is an issue that will hold up the next release of software. All P0 issues must be resolved before shipping.
• P1 -- A very high important issue. While it will not hold up software releases, these issues should be worked on first.
• P2 -- Moderate priority issue. Generally these issues should be picked up after all assigned P1 issues in a sprint are completed. These are nice to have issues.
• P3 -- Low priority issue. These will likely become higher priority once the current higher priority issues are addressed, such as in a future sprint.

Tagging and labels

Classification into Types

1. Question: This is a question that we want user research to answer. The answer may lead to a story.
2. Story: This is a user story
3. Bug: A defect in the product
4. Task: Something that needs to be done but doesn't add functionality to the product or fix a defect (e.g., set up a server instance)

There are a few special types:

1. Quick Win: A story that stands by itself, is well defined in scope, and doesn't require in-depth knowledge of how the product works. The goal is that the public can volunteer, pick up, and complete the story.
2. Epic: An overarching story that describes a suite of user needs, to later be broken down into individual stories.
3. Icebox: An interesting idea, question, or story that is not necessary or of high priority right now, but should be re-evaluated in the future

Issue assignment and blocking

When you are working on a story, be sure to assign yourself to the issue.

If you are blocked on someone or something else on an issue, please add the blocked label. Remove it when the block is no longer an issue.

If an issue needs attention, apply the attention label which indicates an action must be taken.

What about the backlog?

The backlog is handled implicitly: All of the unassigned stories in the current sprint are the primary backlog. If all stories are assigned, then the backlog consists of the prioritized stories not assigned to any milestones. To pick off the backlog, pick from your workflow area (eg, dev) and look for a story with the highest priority. Assign it to yourself, remove the unassigned label, and add it to the current sprint milestone.