1. FEC team task board
The FEC team uses Zenhub to organize and manage all of the work we do. Zenhub requires a Chrome or Firefox extension. Zenhub allows us to view issues from all of our repos in a single place, provides the ability to use epics, gives advanced filtering options and more.
All work done regarding developing both the product and planning for the transition is managed in the same board. This page describes the mechanics of how we manage this board.
At the highest level, we plan our work with epics. Epics may either map to a single feature (e.g. a page of charts) or set of related features (e.g. build several similar endpoints). Each epic should be able to be completed in a span of time greater than a sprint, but under a quarter. When it comes to quarterly planning, the top 10 features will map to individual epics.
Epics all live as Zenhub Epics in the FEC-Epics repo. Epics can be nested inside other Epics, but that’s only useful every so often.
Epics can contain multiple issues from any number of other repos together and are a really helpful way to see all of the work that goes into a certain feature. You can filter epics either with the dropdown:
Or from the card itself:
Within epics are single issues. Issues are a unit of work that can be accomplished within a single sprint. Each issue lives as single GitHub Issue. Ideally, issues live in the repo that houses the code that will ultimately be edited to act on the issue, but it’s more art than science given how things run together.
As a cross-functional team, our issues can take many forms, such as:
- Design tasks to design a new UI component or flow
- Research tasks to scope out the user needs or business logic of a feature
- Engineering tasks to build out a new feature
- Content tasks to write microcopy or organize a series of pages
- Transition tasks to facilitate knowledge transfer with the FEC
We track all kinds of issues alongside each other in our board so that we can have a single view into what everyone on the team will be doing in a given sprint and track discussions of all sorts.
Give the issue a short, descriptive title that conveys the type of work that needs to happen. e.g. “Implement new button for exporting data.”
When possible and helpful, begin the issue with a user story in the form of “In order for [type of user / team / admin] to [accomplish some goal], design/implement [some feature]”. Sometime the same user story will be used across multiple issues encompassing the design / development / content work necessary. Starting with the story helps give context and remind us all what the purpose of the task is. However, some times including a user story is unnecessary clutter, such as for fixing a bug, doing some other low-level task, or working on tooling or process. It’s a suggestion not a rule.
If there were previous issues, research or conversation that would be helpful for anyone reading the issue to know, include it.
When it makes sense, think through a specific checklist of things that will tell us when this issue is done. It could be a description of the necessary aspects of a design, the capabilities of a feature, or anything else. The important part is that it gives a clear understanding of when this is done.
Different from completion criteria, you can also include a checklist of the subtasks necessary to complete an issue. This is useful if there’s an approval process or multiple known steps you need to go through.
When it makes sense, visuals like screenshots are super helpful to include to make sure everyone looking at the issue understands what you’re talking about.
If you know the labels, milestones, epics or columns to apply, feel free to go ahead and do it at the step of making the issue (read below for how to do that), but you can also just leave those off and the PM will apply.
Now, sometimes an idea pops into your head and you don’t have the time or capacity to flesh out a perfectly crafted issue. In these cases, it’s better to capture it in some form than not at all. Try to capture enough meaning in either the title or the body of the issue so that it makes sense to someone other than you and then leave it in the “New issues” column on Zenhub and we can groom it later.
We use Zenhub’s pipelines (which we call columns) to organize our boards. The columns we use are:
- New issues: All new issues end up here by default. From here, an issue can either go into the backlog or the icebox, depending.
- Epics: pods: This is where all epics related to “pod” work go. These include transition, training, research or other administrative type work.
- Epics: mothership: This is where all epics related to “mothership” work go, which refers to epics that address delivering new functionality to the product.
- Backlog: Issues that fall within a current quarter’s priorities belong in the backlog.
- Ready: Once issues in the backlog have been a) groomed, b) are within a given sprint’s priorities, and c) are free of any blockers, they go in ready. These issues may be unassigned until someone begins work on them.
- In progress: Once someone begins work on an issue, they should assign themselves and move it to in progress.
- Done: Once an issue has been effectively completed, it can be moved to done. This is not the same as closed. Rather, issues in this column may still be in a pull request that needs to be reviewed or pending some other form of review. The important factor is that there is no work that can currently be done on them.
- Icebox: Issues that do not fall into a quarter’s priorities belong in the icebox. For easy retrieval, it’s best to make sure that any issue that goes in here has a descriptive title and all the labels that will help find it later.
- FEC Feedback: This is a rarely used column for collecting a bunch of issues that were previously filed by our partners.
- Epics: Backlog: This column is for keeping epics that we’re not currently working on in a given sprint.
It’s easy to go overboard with labels. We have a lot of labels in our repos that have served one purpose or another in the past. Currently, there are only a few that you need to know:
-
Work: Front-endWork: DesignWork: Back-endWork: Content: These labels describe the type of work that an issue requires. This makes it easy for someone to be able to filter down to unassigned issues in their skillset and to give us an overall picture of the distribution of work in a sprint.
-
Mothership: This label is applied to all issues that are being handled as part of the mothership’s sprint. -
Bug: Used to designate a bug that is currently in production -
Before release: Used to designate when an issue must be resolved before a pending release. This is usually just used in the couple days before a release. -
Needs grooming: Used to highlight issues that need further discussion for easy retrieval in grooming sessions. -
plz-review: This is only used for pull requests and is applied when something is ready to be reviewed. If it is not applied, it’s safe to assume the PR is still in progress. -
Internal: This is used to show work that has to do with internal process stuff.
There are other labels out there, but these are the ones that we use regularly. If you know which labels make sense to apply when you file an issue, great. If you’re not sure, you can just leave them off.
In addition to labels, we also use milestones for each sprint. Every sprint should have a new milestone named "Sprint 1", "Sprint 2", etc. Each milestone should have an ending date of the Tuesday that the next sprint starts on. In order to filter issues by milestones, they all need to have exactly the same name and ending date.
Separate from the Zenhub board which includes all of the repos we work in, we also have the FEC feedback repo, which is where issues submitted via the feedback forms on beta.fec.gov go.
For the sake of ease of use, it’s helpful to rename these issues with descriptive titles and apply labels so they can be found later. Once an issue is being addressed, it should be closed and a new issue can be created in one of the existing repos linking back to the original issue. Zenhub’s “Move issue” button makes this super easy.