Skip to content

Scrum Board Guidelines

Ina Odén Österbo edited this page Jul 1, 2021 · 4 revisions

Columns

The board consists of 10 columns:

  • New Issues
  • Ice Box
  • Epics
  • Minor tasks
  • Product Backlog
  • Sprint Backlog
  • In Progress
  • Daily meeting
  • Review/QA
  • Closed

The Ice Box, Minor tasks, Product Backlog and Sprint Backlog are ordered with the highest priority cards at the top (which should also be marked as must have, see Labels at the bottom of this page) and the lowest priority cards at the bottom (which should be marked as could have).

New Issues

Unsorted newly created issues.

Icebox

Low priority Issues and suggestions that do not need to be addressed in the near future. The cards should be labeled appropriately and sorted according to priority level, with the highest priority cards being placed at the top.

Epics

All epics - Major user stories defining the project. The epics have labels on them to show which label you and Epic number you should mark the other tags with. Don't add cards to this column.

Minor tasks

Smaller tasks not requiring a lot of time/effort to fix (a few hours work in total at the most). This column is mainly meant for those aiming to help out so that they can pick small but important tasks when they have time. The cards should be labeled appropriately and sorted according to priority level, with the highest priority cards being placed at the top.

Product Backlog

All planned tasks. The cards in this column are not currently being worked on, but will be at some point. The cards should be labeled appropriately and sorted according to priority level, with the highest priority cards being placed at the top.

Sprint Backlog

Cards from the Product Backlog and Minor tasks are placed here when they have been assigned to a specific sprint (make sure to assign the card to the sprint). Each sprint starts with the team estimating which tasks they should be able to finish within the two week sprint. These (and only these) cards are worked on during the sprint. The cards in the Sprint Backlog are not currently worked on but should be finished before the sprint ends - if there are cards left in the sprint backlog that have not been addressed, they are moved back to the product backlog and a new sprint planning is done. This may result in the same cards being chosen. The goal during each sprint is for all cards to be finished. If that is not the case (specially when a card is moved to the next sprint multiple times) the team needs to reevaluate, discuss potential problems, and possibly split the card into multiple parts. The cards should be labeled appropriately and sorted according to priority level, with the highest priority cards being placed at the top.

In Progress

When a team member begins a specific task, the card is assigned to the specific team member and is moved here from the Sprint Backlog. Only cards in this column should be worked on at a given time. If that is not the case, find and move the card, or create a new one if the original card is a large tasks which needs to be split up into smaller subtasks. If the team member is working on something that was not part of the Sprint Backlog, add a new card. Document everything during a specific sprint.

Daily Meeting

When a task in In Progress is completed, it's moved to this column. On Mondays, Wednesdays (except for the sprint planning meeting) and Fridays at 9.30, each team member should update the others on which tasks they have finished in the last two days. This update should be a maximum of 15 minutes. If there have been issues, these can be discussed after those 15 minutes.

Review/QA

Cards are placed here when they have been discussed in a daily meeting.

Closed

After each sprint meeting, the issues in Review/QA are moved to this column. If they are not already marked as closed, they should be so now.


Labels

There are a number of different labels available in both repositories (dds_web and dds_cli) which are meant to help clarify what the cards are about to the team members. When creating a card, however, make sure to label it with...

  • cli or web interface (this should also be chosen as the repository when creating the card)
  • Epic: Check the Epics column to see which epic you should tag it as
  • User story and/or Task. Smaller tasks (a maximum of about two days) can be marked as a Task. Any task which will take more time than that should either be split into smaller tasks (when moving to In Progress at the latest) or, if the task provides a specific feature which the user will clearly notice, can be labeled as User Story.
  • must have / should have / could have
    • must have: High priority. We need this feature or card to be finished and cannot deliver a finished product without it.
    • should have: Important but not vital. The system works and can be used without this task being done. Do we already have a working solution (albeit not optimal) for the specific feature - then it's a should have.
    • could have: Wanted or desirable but less important. Tasks which would be nice to implement but can be at a later time. The system can be used without it, it's just an enhancement/improvement.