Doing Scrum using Backlog

What is Scrum?

Scrum is a framework based on the Agile methodology. The team works in weekly or biweekly cycles known as ‘sprints’ to develop features in increments or add iterative improvements to the software product.

Doing Scrum in Backlog

A quick disclaimer: There are possibly several ways to scrum in Backlog, depending on your team’s preference. What is suggested here may not necessarily fit your team’s specific situation or habits. I hope you’ll take what’s useful from here and make it your own.

Step 1: Create a product backlog milestone and add user story tasks

In general, a project consists of a series of tasks to be completed by a determined date. Fittingly, the milestone feature in Backlog helps us mark out tasks to be completed within a time period.

So, first, we’ll create a milestone named Product Backlog with the start and end dates filled in.

The Product Backlog contains PBI (product backlog items) or user stories. These are features to be developed for the product or tasks to be completed by the team. We’ll add these tasks/user stories into our project and assign them to the Product Backlog milestone.

Note: To denote user stories, we can use tasks or create a new Issue type in Backlog named ‘User Stories.’ For our example here, we’ll use the default ‘Task.’

Step 2: Prioritize user story tasks using the board

After adding the user stories and tasks, we can prioritize user stories. Currently, Backlog only has three options for task priority (low, normal, and high). To get around this, we can use the Board to drag and reorder them so that the higher priority tasks are at the top.


Reordering user story tasks on the Board will change their order in real-time for other users too. However, the new order will not be reflected in the Issues list and Gantt Chart.

To enter the estimated story points, we can use the ‘Estimated Hours’ field to enter a number for the tasks. This will help in generating the estimated Burndown graph for the milestone.

Next, sprint planning.

Step 3: Create a sprint milestone for user story tasks

A sprint will typically last from one to two weeks, but it’ll really depend on your team’s preference. We’ll create a milestone for the sprint and name it ‘Sprint 1.’

Then, we select the higher priority tasks (user stories) in the Product Backlog. Issues can be assigned with multiple milestones in Backlog. We’ll then assign those tasks to both Product Backlog and Sprint 1 milestones.

At this point, the selected tasks for Sprint 1 have two milestones: Product Backlog and Sprint 1, while the remaining tasks have only the Product Backlog milestone.

Are you still with me? Good.

With the milestones, we can use the Board to filter our tasks based on Sprints or Product Backlog. This will come in handy during standup meetings to discuss any stalled tasks or challenges.

In addition, Burndown charts are automatically generated for the current Sprint and Product Backlog milestones.

Burndown charts show the amount of work remaining (story points of the tasks) versus the duration of the sprint or project milestone. This gives us a guide to whether we are on track to completing on time.

Note: Only current milestones’ charts are shown, i.e. the milestone’s start date has to be before or today’s date in order for the burndown chart to display. If you have milestones that start on a future date, their charts will not be shown yet, saving you some screen space and possible confusion.

Planning and scheduling using Gantt charts

Besides burndown charts, Backlog also has Gantt charts. It makes it easy to schedule task dates by arranging them on your set timeline. Plus, if there are any task dependencies, e.g. task A has to complete before task B can start, we can look out for them on the chart.

It’s easier to spot overlapping tasks in the schedule and to spread the tasks between team members so that they are not overloaded. In the example above, we can probably assign User Story 6 to someone else, perhaps Toby or another member, since Sean is handling User Story 2 in the same sprint.

Step 4: Running the sprint for development

During the sprint, the team works according to their assigned tasks.

When team members make progress on their tasks, they can update their respective task statuses. Backlog has four default options for statuses: Open, In Progress, Resolved, and Closed. If you need more for your workflow, you can create custom statuses, for e.g. “Testing.”

When sprint tasks are closed, the burndown chart will ‘burn down’ accordingly and we can see our sprint progress:

The Burndown chart of the Product Backlog milestone reflects the updated tasks too. This way, team members can easily see the overall project progress and keep their eye on the goal.

Daily standup meetings with the board

Daily standup meetings are a standard ritual in scrum and they can be conducted using Backlog’s Kanban-style Boards because you can view and understand task statuses at a glance.

We’ve received feedback from users that, with everyone working from home due to Covid-19, the Boards have been very useful during online meetings.

Record meeting minutes in Wiki

After the standup meetings or retrospectives, meeting minutes and important information can be documented in the project Wiki. This helps ensure that information can be easily found, team members can refer to or update it whenever they need, and project handovers are smoother.

Exporting data or generating CSV/Excel reports

Reporting is part and parcel of development work, and Backlog makes it easy to gather work information for reporting purposes.

At any time, you can export your Gantt chart in Excel format, or export the details of issues/tasks (subject, status, assignee, start/end dates, etc) in the form of CSVs, Excel, and printable pages.

This data can also be freely used for analysis.

Link tasks with code commits and pull requests

With Git or Subversion repositories on Backlog, developers can version control their code and link issues with git commits and pull requests. This is convenient as developers and project managers can easily check which part of the code was changed for a specific task.


We’ve shared a step-by-step flow of how a development team can carry out scrum using Backlog’s various functions:

  • Milestones and Burndown charts to track sprint progress
  • Boards to track task statuses
  • Gantt chart to track individual workloads and task schedules
  • Wiki for documentation, information-sharing, and collaboration
  • Generate CSV / Excel reports for analysis and reporting
  • Link issues with Git / Subversion code commits and PRs

We hope that this post will inspire you on how your team can do scrum in Backlog.

Please share with us how you’re doing Scrum on Backlog with your team. :slightly_smiling_face: