18. March, 2019
By Lars Kruse
Waffle.io is shutting down, we’re moving to ZenHub. Zenhub has the advantage that’s is a GitHub extension, so from a usability point of view it’s much better integrated in the user interface.
Quite similar to Waffle.io
ZenHub referes to the columns in the Kanban as pipelines. The predefined pipelines are
New issues -> Icebox -> Backlog -> In progress -> Review/QA -> Done -> Closed.
Of all these,
Closed is the only one that is required (default available). The rationale behind this flow is described here at ZenHub’s help page.
In Waffle.io the card’s journey through the columns was defined by labels. ZenHub uses it’s own internally maintained metadata. So to model the Phlow in ZenHub you don’t need to define any labels, just simply rearrange and rename the columns (pipelines) to read.
New issues -> Backlog -> Up next -> To do -> In progress -> Closed
The New issues pipeline was not part of the line up in Waffle.io, but it’s definitely an improvement, it makes the project’s in box is visible, so we’ll keep it and embrace it.
ZenHub doesn’t define it’s own priorities, so we will just continue to use our own labels for this.
ZenHub has it’s own built-in approach to estimates, it’s based on complexity or story points and takes offset in the fibbonachi numbers 1 - 2 -3 - 5 - 8 -13 -21 and then ends with 40.
Waffle.io also had it’s own internally implemented estimates, but we chose not to use them, because the we’ren’t availabel outside the context of Waffle.io. In ZenHub it’s acceptable since we can actually access this data on an API and we even have access to a few CLI tools zhb, zencli and maybe the most promising zenhub-cli which means that we can incoporate this in our automated Phlow.
And since ZenHub is not hosted on it’s own URL like Waffle.io was, but instead it’s made availabel through an extension of the GUI on GitHub it feels intuitive. We’ll go with this.
We will translate the new complextity to ideal-working-hours. (E.g. how “long time would it take, if we gave the issue to a developer who had all the necessary competences, and could work the issue without interruptions until done”).
So essentially we will stop using our own T-shirt size labels and use the built in story points instead, translating the semantics as follows:
Small: 1-2 story points. Medium: 3-5 story points. Large: 8 story points. Too large: 13 or higher.
ZenHub has built in support for Epics, which essentially are Container issues. It seems to work quite well, and comepletely replases our need for “Briefings”.
There are actually a few more features such as blocking dependencies and modelling releases that seems useful, and ZenHub also encourages the use of Milestones, since they play a central role in the quite useful predefined reports. We can examine this further down the process…
We could probably build a small too to make the transition from Waffle.io to ZenHub here’s the MANUAL process I’ve been using for the few projects I’ve migrated so far. It starts, after you have defined the workspace collection and the pipelines…
Before we start… a word on selction and bulk actions: You can click one of the issues on the icon of the assignee, this will enter into selection mode, click on any other issue to add to selections. While in selection mode, an array of bulk actions becomes available as push buttons over the board. Do Your Thing.
The process is really a repetition over almost the same cycle:
status - *one at a time
Consider deleting the status labels previously used in the Phlow - to force yourself out of Waffle today - rather than in two months.
size - *one at a time
Since the use of New Issues is new to us, but default to ZenHub, we need to move all issues from New Issues to Backlog
Epicitem and then
convert to Epic
Rest In Peace Waffle