-
Notifications
You must be signed in to change notification settings - Fork 51
Scrum Practices and the Zenhub Board
A Mind Like Compost
All this new stuff goes on top
turn it over, turn it over
wait and water down
from the dark bottom
turn it inside out
let it spread through
Sift down even.
Watch it sprout.A mind like compost.
— Gary Snyder
We are an agile team and approach work using a scrum methodology. As a general rule we try to keep overhead as light as possible. It's important for the team to understand the current state of in-progress issues as well as those that need to be done in the near team. We refine these processes over time, so both our Agile style and approach to sprinting adapts to the team and organizational needs. Our goal is to improve how we work as well as what we build. Over time we may flex for specific reasons (e.g. we are putting out fires, need to wrap our heads around new technology, etc). Change is constant.
The team works in roughly eight week cycles split into four two-week sprints. Often prior to a new cycle we take a "Bi-Fort-Night" week (or two) to evaluate the board, clean out stale issues, and address bugs so we have a clear mind. During the initial phases of planning we write up an overview Epic for discussion. This is a bulleted list of goals for the cycle. During an in-person meeting we discuss the high-level goals of the sprint as well as any outside influences and pressing production bugs. The cycle's goals are broken into epics and then issues. At each step we may re-evaluate and refine. At the start of the sprint we agree to the work over the next eight weeks, fire a starter pistol, and get to work. During the cycle the goal is to work on issues within the cycle. If there's a pressing production need, those bugs/outages should be pulled into the cycle and labeled high-priority by the PO. If the production issues cause a major break in the cycle, the team lets the PO know who can then talk to stakeholders about repercussions deliverables, timelines, and sanity.
- Each 8 week period is recorded as a "release"
- The goal of the cycle is recorded in an epic for reference. All other epics should be children of this master to make filtering easy.
- Releases should use a date-based naming scheme, cute names can come after the dates 2019-01-10 (Cute name here)
- Sprints are setup as milestones on all related repositories. Zenhub allows creating milestones across boards.
- If new work is added to the sprint mid-cycle, the team members should be sure to add it to the sprint milestone.
- PRs not related to an issue should be added to the milestone a generic "chores" issue
- Sprints should be named by date ranges with cute names afterward, if you're so inclined
- Epics are large bodies of work, thematic or user-based in nature. Examples include: "Batch editing of metadata" or "Golive UI Punchlist"
- A goal should be to have all issues related to an epic which makes organizing the board a bit easier. Because of that, we may have a "catch all" epic such as "bugs and chores" for a cycle.
New issues come in and land in this pipeline. The goal is to move them "icebox" for future consideration or "needs refinement" for discussion during a standup/refinement
This is where any unscheduled ideas or enhancements land. In practice this means anything not slated in a currently active release. Things in this pipeline should be put into a "backlog" milestone (undated) or a "someday/maybe" milestone.
Issues land here when they are ready to be refined for an upcoming or current cycle (release). An issue may either get punted back to the icebox or get refined, slated for the release and placed into Ready. The goal of refinement is for the team to gain a common understanding. That means a description, a done looks like, tasks if necessary and a relationship to an epic.
Issues here are ready to be pulled into a sprint. The team should look at the ready column regularly to help prioritize work. This is critical for time sensitive and dependency heavy issues.
Bugs and chores are small issues that can be pulled into a cycle at any time. Ideally we are working on a bug or two during each two week cycle so the number of bugs and chores does not get overwhelming. This also ensures we don't leave people hanging.
Epics describe large bodies of work in the cycle. Ideally these epics are written from a user (or group of users) viewpoint. Epics may also be used to run a "punchlist" (e.g. frontend release punchlist
Current sprint holds issues to be done during the current two week period. Nothing should be in here that is not in the current two week milestone and eight week release cycle.
Issues that are in progress are actively being worked on. They should be assigned "grabbed" by a member or members of the team. Team members should actively give updates.
Issues with open PRs attached should land here. After review, the team member that owns the issue can move it back to "in progress" if there's a lot of further work or move it to QA if it's ready to be tested on staging.
The issue/pr is on staging and ready to be tested by POs and Subject Matter experts or Developers (depending on the scope of work). Feedback can send it back up the chain.
After QA a PR is attached to move the work into production or if it's a non-code change the task is "done". When it's ready to be viewed/ OK'd on production, the issue and associated PRs should move to this column.
The PO/scrum master will close out issues from the done column after final sign off/testing/etc on prod.