Like many people we’re used to working with Jira and other big tools for project management. These tools work quite well for large projects and teams. But at Colloq where we are only three people, using Jira would hinder our productivity—it’s too complex for our use case. That’s why we decided to use a tool we already use: Github.
In general, we try to use as few tools and services as possible. This makes us less dependent on third-party solutions. It also challenges us to search for the root cause of a problem instead of trying to solve it with yet another tool. As a result, we become more effective and by doing so, also limit our cost for external services.
From the start, we used Github as our remote source code management servers. We use Pull Requests to review our code and to validate ideas. We went with Github issues for our tickets—which at some point gets pretty hard to manage.
When we discovered Github Projects, it eased a lot of the challenges we faced with how we organise our work. Having a board that reflects the status of our work is a neccessity for working in a team. The features of these projects are still limited, but we found ways to make it work as our complete project management solution. Here’s an overview on how we use it and make the most of it:
We use issue templates to ensure every fresh ticket holds the required information. For each new ticket, the author should fill in the following information:
- A clear and descriptive title that shortly describes the ticket’s purpose
- A complete User Story. It describes the ticket’s purpose from a user perspective to make clear what value a user gets from the change.
- A granular Definition of Done. It’s a bullet point list with checkboxes. The items are small individual tasks that need to be done before this ticket can be marked as completed.
When someone creates a new Pull Request, they add the preview URL of the branch build (1) to the description. Additionally, they add relevant screenshots of the changes to the description. This makes it easy for others to understand what the desired result should look like. We also add informative links to Pull Requests, such as dependencies, blockers, or other helpful information.
This pretty much reflects the body of each issue we create. Now let’s have a look at our added meta data:
We heavily make use of Github’s Labels to categorise tickets properly. Labels serve various information for tickets. For example they imply the priority of the ticket via a
[Prio] High label. We also state the type of ticket, such as
Since it’s possible to add an indefinite number of labels to a ticket, we also use labels to show required actions. Labels like
⚠️ story needs review or
non-commitment story are used in such case.
To predict important milestones, we use Github’s intended feature: Github Milestones. They are an organisational wrapper around specific tickets with an end date. The cool thing is that Github provides a progress indicator automatically.
One thing we only found out after some research is that when you change to the Milestone tab on the issue overview page, you get a view where you can drag and drop the issue list in a customised order. This is ideal for having a sorted Product Backlog indicating the correct priorities.
Emojis to the rescue
By now you might wonder how we figure out how much effort a task is. We do that by estimating the complexity of a ticket in Story Points. They follow, as suggested by Scrum, the Fibonacci number sequence.
To immediately identify the Story Points of a ticket, we add the number via unicode emoji to our issue title. Here’s an example:
5️⃣ Issue Title.
For Epics, we use labels so we can filter them. But it’s easy to overlook the label in the issue overview so we decided to add an emoji here as well:
🏋️ Epic Title.
Our Project Board
During a Sprint, we work from our Project board. We currently have four columns in our board:
- Sprint Backlog
- In Progress
- In Review
- Is Done
Every column reflects the status of each task during a Sprint. When someone starts working on a task, they assign themselves to the ticket and move it to “In Progress”. From there the ticket moves from left to right, and only vice versa if it failed the review or has an impediment.
Additionally to the cards we have on the board, we use the Project description to hold our meta information:
- Sprint Goal
- Team Capacity (indicating who can invest how much time in this sprint)
- Committed Story Points
- Achieved Story Points
- Emerging Task Count and Story Points
- Burndown Chart (manually updated, referenced as an image)
- Team Retrospective Notes
- Mood board: Use one emoji to indicate how you feel about this sprint individually.
- What went well? A list of things that went well during the sprint.
- What didn’t go well? A list of things that sucked.
- Improvement suggestions: A list of things that we want to improve as a team.
- (Kaizen) If immediate action is required to fix something, the team can decide for a Kaizen story. It then gets the highest priority in the upcoming Sprint.
Since it’s possible to use Markdown in the Project description field, it even looks nice after all. It’s only a bit verbose in the project overview list.
Besides Github as our code and project management tool, we use some other tools to communicate as a team.
We use a free Slack team for now where we have short chats, share links or screenshots to discuss things. We have a few service integrations. Github so we can see new Issues and Pull Requests in there. Circle CI to inform us about broken CI builds or a finished branch build environment. Besides that we have a Twitter integration so we can handle communication efficiently and see who writes about us.
Slack provides a nice overview to everything that’s going on in our project in a single place. And in the end, it’s the easiest communication solution for now that enables us to focus on working on our product.
As we already mentioned in our previous article, we do group calls via appear.in, a WebRTC tool. It’s quite reliable and even offers screen sharing without any plugins on Firefox.
Tip: Don’t use appear.in’s video calls on your mobile data plan, since its video is HD quality and it will likely eat up your data plan for the month 😉
Sometimes less is more indeed
During our time working on Colloq we realised that we don’t need a lot of tools to run our project. Instead, we try to focus on our most important tasks. We try to understand our real needs, and we tweak the available options we have to match our needs. We lower the complexity in our product by reducing the tools we use. We believe that this is one of the reasons we currently work very efficiently on our product.
- We have a workflow that creates a separate instance of our application for each branch and builds it via Circle CI. The branch builds are then served as a subdomain on our staging server and can be accessed by anyone in the team. When, for example, a branch
feature/awesomeis pushed, we can access the branch build on
https://feature-awesome.stage.colloq.io/a few minutes later.