Working on Nebulab
Nebulab, the company, is run by a group of 4 directors who handle all aspects of it: strategy, team building, sales, marketing, client retention and everything else that is not the day-to-day work of our team members. With so many aspects to cover and such a small management group, things can quickly become overwhelming if tasks are not prioritized correctly.
In July 2019, we completely revamped our approach to running Nebulab. We decided that we wanted to run the company like a product and adopted Scrum as our methodology. Today, all management work goes into Scrum sprints to be categorized, prioritized and executed.
We use Jira as our task management tool. For estimates, we use the excellent Planning Poker Jira add-on.
Our work is split by epics. We don’t use epics in the traditional way, but rather as a means to categorize and identify the goal each task is aimed at. In fact, each epic is a business goal for Nebulab.
Tasks that don’t fit into any of our epics probably don’t bring us closer to our goals, and should be either executed outside of the sprints or dropped entirely.
For a more detailed explanation of Scrum ceremonies, you can read the Scrum Guide.
The rest of this section will cover how we use Scrum at Nebulab specifically.
Our standard sprint duration is 4 weeks, Thursday to Thursday.
Every Thursday, we have a standup meeting. We meet over a video call and every member of the sprint answers the following questions:
- What have you done this week?
- What are you going to do next week?
- Any blockers impeding your progress?
That’s it, no discussion or comments allowed. If you want to discuss a member’s standup further, you can ping them on Slack and chat or schedule a follow-up call.
On the last day of the sprint, we hold a sprint retrospective, where we discuss how the sprint went, what challenges we faced and how we can do better for the future.
The retrospective is run by using our own version of the Six Thinking Hats methodology. The thinking hats force us to consider different angles of the topic we’re discussing.
At the end of the retrospective, the Scrum master summarizes the next steps and transforms them into Jira issues, which will then be prioritized along with the rest of the tasks.
After the retrospective, we run a sprint planning session.
The Scrum master chooses a name and outlines the goal of the new sprint, then goes through each issue on the backlog, sorted by priority, and decides - along with the team - which issues should be part of the sprint.
Once the issues have been chosen, they are weighted in a planning poker session. We use the Fibonacci scale, up to 13 (1, 2, 3, 5, 8, 13).
Once the issues have been moved into the sprint and weighted, the Scrum master starts the new sprint and work begins.
All members are free to add issues to the Jira board if they can be assigned to one of the epics/business goals.
We don’t have formal backlog grooming sessions: we understand that most of the issues in our Jira board will most likely never get done because they are not really important, and don’t want to waste time describing them and/or weighing them unnecessarily.
Instead, issues are only defined and weighed when they are put into a sprint.