How we developed Backlog’s Board feature (Part 2)
Nulab Staff
July 02, 2020
In Part 1, I shared about our development methodology, user stories, Gantt charts, and Burndown charts for tracking project progress.
For Part 2, I am going to discuss our Sprint workflow and how we used Boards in our daily workflow.
We will be covering the following:
- Subtasks: Defining work
- Board: Daily development workflow
- Sprint Meetings: Using Boards to discuss work
- Constantly improving Boards
Subtasks: Defining work
At this point, we have a list of detailed user stories and non-user story items that we’ve prioritized in our product backlog.
Now, it’s time to create subtasks, so we can break each of these user stories (i.e. parent tasks) down into smaller, more manageable parts. These subtasks (i.e. child tasks) will define the actual work to be done in order to complete a user story.
Using subtasks in this way will make it easier to divide up work amongst our team, estimate story points, and manage Sprints.
Milestones for releases vs. Sprints
How we break down our subtasks in Backlog is important; with the proper application of milestones, we can easily track our overall project and Sprints throughout the project.
For our project, we assigned all parent tasks to a release milestone (e.g. Alpha release.) while we assigned all child tasks to a Sprint milestone (e.g. Current Sprint.)
While this might seem confusing at first, we used this technique for a few good reasons, which we’ll explain now.
Avoids inaccurate story points
The Burndown chart feature in Backlog is generated based on milestones, and it has a specification for parent tasks and child tasks, adding up their estimated time/story points to give a total number. If the estimated time is left blank, it will count as ‘1’.
For our use case, where child tasks are the actions needed to close the parent task (product backlog item), we would have seen story points counted twice when parent and child tasks had the same milestone. This would have caused the total number of story points to be higher than the actual situation.
To avoid this, we used separate milestones: (1) Release milestones for our product backlog parent tasks and (2) Sprint milestones for the child tasks.
Aside from this reason, though, there are other advantages to using separate milestones.
Allows quick Board filtering by release or Sprint
By grouping the release parent tasks and the Sprint child tasks into different milestones, we can now use the Board filter to view each separately.
This is useful for team meetings, sprint planning, identifying bottlenecks, etc. And since there is almost no lag when using filters, using this option is quick and seamless.
Makes it easy to track Sprint history
After each weekly Sprint, I transfer the “Current Sprint” milestone items to a new numbered milestone, which I’ll call, for example, Sprint #25.
Using the batch update feature, you can quickly update many tasks at once. Use the same milestone, and your sprint will then be captured in your records forever.
Even better, Backlog’s project home page — which displays a summary of all milestones — will then show a list of all present and past Sprints for you to see.
To dig deeper, just hover over the milestone title and click on the ‘Release Notes’ button to access more details about that milestone.
Add tasks in an instant on your Board!
Using your Backlog project’s Board, you can add a task directly just by typing in a one-line issue subject/title and pressing the Enter key.* It’s a fast way of adding tasks.
*If your project does not have custom fields with mandatory input.
Keep in mind: Whatever filters you have applied to the Board will also apply to the new task you’ve created. For example, if you are viewing your Board with both the “Current Sprint” milestone and the “Website” category selected, then when you add your task, that task will have the “Current Sprint” milestone and “Website” category too. Convenient!
Board: Daily development workflow
After building the Alpha version of the Board, we started using it in our daily workflow to organize our tasks and keep track of work, while continuing to improve upon it.
Here’s the daily routine for our project developers.
1. Open Backlog Board and select the milestone ‘Current Sprint’
By filtering tasks to the “Current Sprint” milestone, the developer can see all the timely issues, keep track of who’s doing what, and view task statuses.
Members can also click on the cards to view more information related to the specific task.
2. Check for tasks assigned to them and get to work
By clicking on the “Assign to myself” button, developers can filter by tasks that are assigned to them, and start work.
If there are no tasks assigned to a developer, they can take a task from the Open column that is not assigned to anybody yet, and work on that.
3. Move to the next milestone if all tasks here are taken care of
If there are no open tasks on the Board, meaning they’re all assigned or being worked on, developers can filter the Board to the major release milestone (e.g. “Group 1 release.”)
They can then take a top priority user story from this major release milestone, create a child task for it in the “Current Sprint” milestone, and work on that task.
Rules for creating tasks
Our rules for creating tasks are documented in our project Wiki, so that team members can easily find them when needed.
Sprint Meetings: Using Boards to discuss work
During our weekly Wednesday meetings, we’ll open our project board and filter it by the current major release milestone, e.g. Group 1 or Group 2 release. Followed by:
- We’ll demonstrate features that are waiting for release in our dev environment.
- Then, we’ll look at the features that are in progress, and check their child tasks, too.
- For open tasks that are ready to be worked on, we’ll assign them to developers and move the tasks to the “In Progress” column/status.
- Along the way, if we find additional work, we’ll create tasks for each item on the Board.
After looking at the major milestone, we’ll switch to the “Current Sprint” milestone. If we need to discuss any issues here, like anything that is blocking our work, we’ll discuss it and find solutions.
Constantly improving Boards
We’ve come to the end of this two-part article on how we managed the development of the new Board feature. We will continue to improve it iteratively.
When used with milestones, start/end dates, Gantt and Burndown charts, and more, it is a powerful tool to complement any project management workflow.
Your team may have a slightly different process, but we hope that learning about ours helped spark some ideas.
We would love to hear about your experience using Boards. Please join our Nulab community and share it with us!
