Kanban board within GitHub — a simple solution for small startups
How to create and use custom columns for successful development management
You are an early stage startup with a small development team building an MVP — keep it maximum simple possible :). Here is a suggestion for managing your software product development right there in GitHub — where your code lives (and will live happily ever after:)).
On your GitHub organization page, pick the repo you want and just after the Code tab, you’ll see the Issues. This is a place where you can create issues (tasks, feature requests, bug reports — use custom labels to match the terminology you feel natural with) and sort them by label, assignee etc. Once an issue is created, it’s ready to be added to the board — and that’s where you wanna be right now. Locate the Projects tab and create a new one. Clicking on it opens The Board :)
Here is the suggestion for columns you could add:
- Backlog — anything that reaches the dev team and stands chance to be implemented at some point
- Elaborating/Estimating (activity) — when a feature request gets picked from the Backlog (say by the startup founder, product owner etc., depends on the organization) the dev team starts analyzing, asking questions, leaving comments, elaborating. The output is an issue with the estimated effort (don’t forget testing, and padding of course :)). The developer moves it to the next column.
- Estimated (state) — the manager (or a GitHub2Trello zap from Zapier) informs the decision maker (founder, product owner). For the flow on the requirements engineering side check out my blog post The dev flow is great, but what about the requirements flow?. That’s the missing activity between these two states.
- ToImplement (state) — At this point the issue is clear and it’s priority has been set (use labels such as Low, Medium, High, Blocker). It can be assigned to a developer by the manager, or left for the developers to pick an issue once they are available. For an already experienced team, it’s nice to leave this freedom to the developers, whereas with newly joined team members sometimes it could be better to make a suggestion. Just some common sense.
- InImplementation (activity) — just as it sounds.
- ToTest (state) — The developer will move an issue here when it’s deployed to the QA server. And here is where the QA expert will take a look with their morning coffee.
- InTesting (activity) — QA can return it InImplementation if it doesn’t meet acceptance criteria.
- AcceptedByQA (state) — Should be deployed to staging. The manager/zap asks the user/customer/founder/product owner to check it out. For the flow on the out-of-dev side, as mentioned, please refer to my blog post The dev flow is great, but what about the requirements flow?. User acceptance is the missing activity between these two states.
- Released (state) — in prod, live :)
A few additional suggestions to consider:
- Adding a task list when creating an issue is an excellent practice. The (sub)tasks makes it easier to estimate, implement, test in more systematized and structured way.
- Add acceptance criteria on issue creation time, it’s needed for the estimation, implementation and testing.
- Remember to put the issue number in each commit comment, your code will be linked and one click away as well.
- The QA expert might get into a habit of taking a look at the issues InImplementation to be ready with the test scenarios when the time comes. In addition, if the QA expert shares the test scenarios at this point, the developer might find it useful when adding the automated tests. See if it works with your team!
- For the agile process, iterations concept etc., please refer to my blog post How to Scrum with a freelance team
Good luck and go with the flow!
I help startups set up their software product development. Lean, agile, remote. Check it out at: www.tijanamomirov.com