Hey there! Most teams that I work with are used to working with tasks which represent bite-size parts of a Story. Using Jira or Azure DevOps, this wasn’t an issue, but GitHub is quite limited in that respect.
Although GitHub/Zenhub support tasks as a checklist within an issue, this isn’t visible on a board, i.e. the associated story shows as “in progress” for the whole sprint, whereas if you had a task breakdown you’d see tasks moving across the board during the whole sprint.
Right now we’ve worked around this problem by creating an Epic (feature), then nesting other Epics within it that we label as Stories and then creating issues within those “stories” that we treat as tasks. Although this works, it’s not pretty and can get confusing.
The latest beta of GitHub issues offers progress tracking for tasks directly on the issue, but you only see this progress if you open the issue (you don’t see a completion percentage directly on the board as far as I know).
Does anyone else face the same issue? How do you resolve it?
Hey Sascha,
We think of issues as the smallest body of work. Task list, or checklist, inside the issue can help determine what “done” means for the issue, or guidelines on the steps to take. We’ll use sprints to track our short term goals, but use epics and projects for longer term tracking.
Hi Julie! I may have been unclear, but our tasks are in issues at the moment, our structure is: Epic (real epic) > Epic (stories) > Issues (tasks). The problem with nesting Epics inside of Epics instead of having a separate entity is that on the board they all look alike at a glance.
I haven’t used projects within GitHub yet, do those appear as cards on the board with the Epics linked within them?
One very common pattern we see is the use of an Epics column for your Epics, and the Stories in another column (or moving across the board). This will absolutely help with them blending into each other.
A pattern that has emerged for me is using a 2 deep hierarchy of epics (I think similar to what Sascha is doing) for the following purpose (and I’m curious if I’m abusing the system or if there are better methods here)
Epic for Customer X
|-Epic for Feature A
|-Epic for Feature B
Epic for Customer Y
|-Epic for Feature A (shared with above)
|-Epic for Feature C
And currently as suggested by George, I have a column for epics, but now I’m going down the rabbithole of having 2 columns for epics so I can easily filter on the parent epic without having to find it swimming amongst the rest.
It feels like my top level epics should map more to releases or projects, but I want to be able to filter a group of epics right on the board and take advantage of that hierarchy. So clicking filter epic on Customer X shows me the feature epics that are children of it, and the issues that are parented, etc…
And I believe for releases as they stand, I’d have to label every issue/epic with the Epic + Release to have filter work. If the release filter was smart enough to see an epic tagged with a release, then pull in its children issues without them having to be individually labelled that might work.
Besides sharing features across multiple epics, Shawn’s setup mimics ours. The filter button on the Epics is the bee’s knees, that’s why being able to do the same for more than one type of artefact (Epics and Features for Shawn, Epics and Stories for me) would be a game changer; Epics could remain highlighted in blue, the other level could be in green or some other color… that would be incredibly helpful.
