Why keep everything in the sprint board

January 4, 2016

 

Sprint board columns

I think most of the times a sprint board has the following columns.

  1. Not Started

  2. In Progress

  3. Testing

  4. Done

 

 

 

Many teams consider number 3 as part of number 2 so you have only three columns in the sprint board. Whatever the case is, I want to point out the importance of the sprint board and why it should be the point of reference for every scrum team during a sprint.

 

Sprint board as the point of reference

A team working in a sprint, could become very busy. Apart from the coding tasks that developers have to do for a user story, plenty of relevant but not code tasks are there to be done too. 

 

 

 

Code review is a task that the team members should do. Also updating documentation might be a necessary task after a completion of a user story. Many teams are facing problems during implementation and they need clarification from the PO and this could be considered as a task too. Things that may be forgotten due to the heat of the sprint must be immediately placed in the sprint board and when the team has some time they could discuss them.

 

Everything that is relevant to a user story could be considered as a task. With this in mind, putting a user story to Done status means that every task must be done first. So its much easier for the team to have gathered everything in the sprint board.

 

Going back to the sprint board.

Its not enough to put things to the sprint board. You have to remember to go back to sprint board many times in the day. You have to make it a habit! 

 

First of all, you have to update the code tasks you have since they are the things that you work the most in the day. Also you have to check if a team member added a new task which requires something from you.

 

 

 

For example a task which says that the code must be reviewed could appear. I know that this can be handle just by making a pull request or just ask a colleague to do it but again its different when you have a task related to it.

 

People tend to forget (or pretend to forget sometimes). Its more difficult for someone to move an unfinished task to Done status declaring that she did it, than to just agree with another team member that she will do it and not doing it. Visible items create more responsibility!

 

A good time to remember the sprint board is the daily stand up or daily scrum. Its good to stand in front of the board and talk about the tasks.

 

Type of sprint boards

I know many teams are using physical boards. I never used them so I cannot say which are the pros and cons. But I imagine that its more difficult than a software sprint board. 

 

I believe that software sprint boards provide more stuff than the physical. First of all the team can have historical data of the previous sprints at once. Many software tools have capabilities such as release and sprint planning. Items from the backlog could be planned for release, sprint etc immediately.

 

 

 

Time tracking on tasks is much easier and also graphs can be produced to help the team visualize the progress of the sprint and the release.

 

Another important thing is that you have plenty of space to write user story details without worrying about it like when writing text by hand in a Post-It note. Also attachments and references to other document links could be added as comments in the user story or task.

 

Types of tasks and colors

I like to distinguish the types of tasks by using different colors on software Post-it notes. For example all code related tasks can have the classic yellow color. Bugs found during development can be marked with Red color. Documentation updates as Blue color and so on.

 

 

 

Ask for clarification tasks and impediments could also be added as tasks in a user story. Even if team member wants to discuss something but the rest of the team has no time, she can put it as a reminder task in the user story.

 

Colors make it more easy to see the big picture fast before start reading the texts. So for example if you see many colors of request for review tasks then you may decide to make a pause from your code and do some reviews in order to move things to done.

 

Done means Done

So imagine that in order to finish a user story all tasks must be in the done column. That's good when you have gathered all the related tasks of any kind in the sprint board. You will know at any time what is missing for the story to be done.

 

 

 

Having only code tasks in the sprint board and the other ones in other software tools or boards, creates a risk of forgetting something which is not related to code but important to be done in relation to a user story.

Please reload

Featured Posts
Please reload

Nikos Raptis -
Agile Coach, Speaker & Developer

I'm a scrum master, speaker and software developer. I love Agile values and principles and...

Contact me

© 2015 Created by Nikos Raptis

  • Google+ - Black Circle
  • Twitter Black Round