How we Use GitHub and ZenHub with Scrum

Organizing Epics

We represent the addition of a new feature or some other unit of work spanning a single sprint as an epic.

In some cases if the work will span multiple teams, we use the multi-level epic feature in ZenHub to make one high-level epic with sub-epics that pertain to each team. However this is as far as we go in nesting epics; while it's possible in ZenHub to have sub-sub-epics and even sub-sub-sub-epics, down this way lies madness so we limit ourselves to just two levels.

Labels

We use GitHub labels to help classify and organize issues and epics.

Here are the labels we use:

  • project/* - Identifies which project (aka which team) an issue pertains to. Values are data-plane, blue-stack, red-stack, scalez. Sometimes an issue will be tagged with multiple projects if it pertains to more than one, but we try to avoid that interdependency when we can.

  • crate/* - Identifies the crate (or really, "crate family") that an issue pertains to. We don't always use this, it depends on the issue whether or not it makes sense to capture this. Bugs should always be tagged with the crate the bug is in, if known. New features or additional functionality should only be tagged with a crate if the issue explicitly pertains to that crate. For example, an issue to add a capability to our logging framework cheburashka would be tagged crate/cheburashka, but an epic that adds some new telemetry feature would not be tagged that way even though some of the work will touch the cheburashka crate.

  • phase/* - This is an experimental convention. It might not be retained, or it might be migrated to a release or milestone instead. This captures what phase of the work leading up to and including the Elastio MVP this item pertains to. In general, work in earlier phases takes priority over work in later phases, so this is a convenient handle for organizing work by coarse-grained priority.

    Phases are things like alpha-1, alpha-2, beta-1, mvp, and post-mvp

  • bug - This is a bug. Sometimes the line between "bug" and "feature" is not obvious, but nonetheless sometimes we want to be able to view and manage all defects separately from all other work. A bug that isn't tagged this way might get lost in the backlog grooming shuffle.

  • ci - An item that pertains not to the product itself but to our CI/CD infrastructure (this includes our dev and test AWS accounts).

  • groomed - Once an issue has been completely processed during grooming and doesn't require any more consideration, we put this label on it so we know to skip it next time we groom. This label can also be removed from an issue if a material change is made or if a question is raised that requires further discussion.

Sprints

While ZenHub has recently introduced support for sprints as an explicit entity in their data model, we have not migrated to this feature yet. We still use Milestones for each sprint. At the start of sprint planning (usually in the evening on the first day of the sprint after planning activities) all tasks in scope for the sprint are set to the milestone for that sprint. If tasks are not completed in a sprint, then after the next sprint's sprint planning if those tasks are still in scope then they are assigned to the next sprint's milestone.