Skip to main content

Should we have or avoiding having a Task Board?

Last post 07:13 pm October 19, 2017 by koti Reddy Bhavanam
2 replies
06:08 am October 18, 2017

Generally we track progress of the Sprint on a Scrum board.

We create cards for each User Story and move them across the value stream mapped on the board.

However, most of the times the Sprint has less than 5-7 User Stories that move more or less together on the board.

So, there is little insight which we get from the progress just by looking at User Stories card. 

Since we add Tasks against each User Story that gets worked on by multiple team members, we thought it would be a good idea to create a Task Board.

However, we also doubt that the Task Board may get interpreted as way to represent progress purely based on the number of Tasks that are Pending, In-Progress, Closed. This will also lead to team member specific questoins that didn't arise until now on why certain Tasks are in a specific state rather the progress being reported.

Should we discard this idea and really only on the Burndown Chart or should we have a Task Board. Please suggest what is the most suitable approach by Scrum methodology.


02:46 am October 19, 2017

Scrum guide doesn't talk about Scrum board or a task board so you might not find any one recommended technique, there are zilllion and it depends on what suits you.

I see you have loads of doubt on a practice that the team has decided that might work for them, why don't you give it a try and assert all your assumptions ? if it doesn't workout then change it and that's what Scrum guide does say, inspect and adapt.

This will also lead to team member specific questoins that didn't arise until now on why certain Tasks are in a specific state rather the progress being reported.

Don't you think this will help create transparency ?


06:00 am October 19, 2017

While there are many ways to raise the transparency during the sprint and inspect the progress towards the goal, chose the one what the development team decides, inspect and adapt as the product development emerge. Scrum framework does not recommend or prescribe a single practice to do this while there are many practices available as one size can't fit all.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.