-
Notifications
You must be signed in to change notification settings - Fork 19
Team Process
The core Punchcard team's process takes inspiration from various Agile methods. We use ZenHub to extend GitHub's built-in project management capabilities, so installing their extension is recommended in order to work along with us. We also recommend reviewing our Contributing Guidelines and Label Style Guide.
All new issues that get created start in the New Issues pipeline. Issues that do not follow our Issue Guidelines are labeled with the stub label. Once an issue meets our issue guidelines, as agreed upon by two or more non-authoring Punchcard team members, the stub label is replaced with the consumable label. During the next backlog grooming session, Punchcard team members will evaluate new issues labeled consumable, size them, and add them to the Backlog pipeline.
The Backlog pipeline is the prioritized list of issues that the Punchcard team is prepared to work on. Issues at the top of the pipeline are the highest priority, bottom the lowest. All issues in the Backlog pipeline need to be sized and consumable. When doing sprint planning, issues at the top of this pipeline should be considered first.
The Todo pipeline is the prioritized list of issues that the Punchcard team is actively prepared to work on. Issues at the top of the pipeline are the highest priority, bottom the lowest. All issues in the Todo pipeline need to be assigned to at least one individual, be sized and added to a sprint. Issues move from the Backlog pipeline to the Todo pipeline during sprint planning. Issues may only move into the Todo (or later) pipeline outside of sprint planning if two or more Punchcard team members have agreed that the issue meets the requirements for moving into the Backlog pipeline and the Todo pipelines.
Once work on an issue has begun, it is moved into the In Progress pipeline. Issues in this pipeline must meet the requirements of both the Backlog and the Todo pipelines.
Once an issue is ready for other members of the Punchcard team to look at and be accepted into Punchcard, they are moved to the In Review pipeline. Issues at the top of the pipeline are the highest priority, bottom the lowest. Pull requests are automatically placed in this pipeline; otherwise, all issues in this pipeline must meet the requirements of both the Backlog and the Todo pipelines, and should have been through the In Progress pipeline. Issues can be accepted into Punchcard once all requirements as outlined in our Contributing Guidelines have been met.
| Monday | Tuesday | Wednesday | Thursday | Friday |
|---|---|---|---|---|
| - | - | D, R, SP | BG | |
| BG | BG | |||
| BG | - | - | - |
- BG - Backlog Grooming
- D - Demo
- R - Retrospective
- SP - Sprint Planning
Backlog Grooming is a 30-minute meeting that happens 16:30-17:00 Eastern. During Backlog Grooming, the team goes through our New Issues, determines if issues labeled consumable can be sized and moved into the Backlog, and issues in the backlog are prioritized. Time permitting, issues in New Issues that have neither the stub nor the consumable label are reviewed to see if either of those labels need to be applied.
Demo is a 60-minute meeting that happens 14:00-15:00 Eastern at the beginning of each sprint. During Demo, the team goes over the issues they've completed the previous sprint, walking the team through their work. This provides all team members the ability to see everyone's work from the previous sprint.
Retrospective is a 60-minute meeting that happens 15:00-16:00 Eastern at the beginning of each sprint. During Retrospective, we discuss how the previous sprint went; things we would like to continue doing, things that did not go as expected, things about our process we'd like to improve upon moving forward. These are blameless meetings, designed to be open and honest without fear of repercussion, to allow the team and the project to grow in a healthy and sustainable manner.
Sprint Planning is a 60-minute meeting that happens 16:00-17:00 Eastern at the beginning of each sprint. During Sprint Planning, the team goes through the Backlog, assigning issues to one or more individuals to complete, adding those issues to a sprint, and moving those issues into Todo.
The following terminology is borrowed from various Agile practices.
A pipeline is a representation of a step in the process towards completion. Pipelines are usually visualized as columns, with each pipeline arranged in order according to their position in the overall process. When arranged together they form a board.
An issue's size represents its relative difficulty and risk, as compared to all of the other issues we have in our project. Difficulty is the amount of effort it will take to complete an issue. Risk is how likely this issue can be completed in a sprint. Risk can encompass such concepts as if all prerequisites can be met, if all required research can be completed, if the difficulty may change given unknowns before starting work, etc… Size is measured in story points, a unitless number. Size is not a measurement of hours of work required to complete an issue.
A sprint is a 2 week period of time in which the team commits to getting certain issues completed. Constraining the working window to a short period of time allows the team to change direction quickly, as needed, ensure progress is made and iterated on rapidly and provides a human-realistic period of time to plan into the future. Planning longer than 2-3 sprints into the future with meaningful fidelity becomes difficult with fast moving projects, so sprints allow teams to keep themselves honest with what they're able to deliver. Our sprints start on Thursdays and end on Wednesdays.
Every individual participating in a sprint has a maximum number of story points they are able to confidently accomplish in that given amount of time. When an individual is assigned an issue, they are committing to completing that in the given sprint, and the issue's size is subtracted from their overall capacity. Capacity varies by individual, based on how much of a given sprint they can devote to completion of issues on their own. Individuals who spend a lot of time reviewing the work of others, like leads, or if someone is out for a period of time during a sprint, may have their capacity lowered. A baseline capacity of 21 should be used, and adjusted up or down as needed per individual per sprint.
An epic track multiple issues together towards a desired outcome, independent of sprint. Epics should be labeled with the epic label.
Stories are sized with story points which are a unitless measure of difficulty and risk based on the Fibonacci sequence.
Difficulty is the amount of effort it will take to complete an issue, but not necessarily number of hours of work something may take. Something can be easy, just take a lot of time to do (going through all of Greenkeeper and merging PRs, for instance). Something can be difficult but take a short amount of time (dead-lifting a tonne).
Risk is how likely it is that something that can be completed this sprint. So “I know this Node module exists and does what I need” is low risk. “I don’t know if this exists, and if it doesn’t, or doesn’t do what I need, that’s going to add a lot of effort to this story” is high risk. Risk also encapsulates research that may need to be done to get something accomplished
Size Descriptions and Examples
| Size | Description | Examples |
|---|---|---|
| 1 | Mindless work | Small copy updates |
| 2 | Mindless work with a hint of difficulty or risk | A bunch of copy updates, a few updates to markup |
| 3 | A smidgen of difficulty or risk | Small, well-defined enhancement to existing feature, with a few additional tests needed |
| 5 | A little difficult or risky | Adding new functionality within a reliable system |
| 8 | A little (more) difficulty and/or a little (more) risky | Developing a database schema, automating a new system |
| 13 | Difficult or risky (or a combo) | Integration with a new critical system for the first time |
| 21 | Very difficult or risky (or a combo) | Working with a well-known terrible third-party or investigating and implementing some new form of authentication |
| 22+ | This is an Epic |
Working on Punchcard
Org Maintenance
Architecture Planning
These architectural discussions may be out-of-date given the current state of Punchcard.