How we developed Backlog’s Board feature (Part 2)

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

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.

Release milestone (parent tasks) and Sprint milestone (child tasks)

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.

With multiple milestones, you can filter different views for your Board.

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 start/end dates, and your sprint will then be captured in your records forever.

Batch update helps update multiple tasks easily in one go.

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

Continue reading

This post was originally published on this site