Search
Close this search box.
Search
Close this search box.
Search
Close this search box.

Scrum Board Setup Tips and Tricks

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

I’d like to share with you some tips and tricks for setting up a scrum board I usually share with my clients. The bottom line is that too many tools have too many features that support old ways of thinking. Let’s look at the various items one by one.

Subtasks

Like the human tailbone, subtasks were once useful but are now mainly a source of pain. When we worked in Waterfall we measured progress with completed subtasks, but in agile when stories are short, subtasks are a burden.

A burden for developers who need to mess with subtasks using the ALM tool.

This a burden for managers who measure progress using a burndown chart that usually relies on subtasks estimation. That’s a burden because burndown charts may time tell an incorrect story (all work done but nothing is working) – progress should be measured by “done” stories, usually a burnup chart.

Using subtasks should be a choice given to developers. If you find it useful then use it. I prefer just discussing the work to be done with the other people working with me on a story. If needed we can write it down on a whiteboard, but usually, there is no need to write it down as the story is so short. We just do the job.

Showing subtasks on a scrum board takes the focus from stories getting done to subtasks. It makes the scrum board too clattered and worse of all it lets people focus on their specific job and not on the story getting done. Bad subtasks! Bad!

Swimlanes 

Another evil thing is swimlanes. Second only to subtasks.

People usually need swimlanes because there is too much information on the board. That’s indeed a problem. Many times it will be … subtasks! If it isn’t subtasks it may be either the stories are too small or the team is too big. Or maybe something else.

The idea is we need to see why are there too many items on the board and handle that problem.

The big problem with swimlanes is that it distracts you. When you have swimlanes it is difficult to see what is now in progress. This is because usually there will be items in the “to do” column which will make the swimlane too wide to see all the items in one column.

Your focus is on the things that are now in progress and that’s what you need to see.

Many times there is a swim lane per team member. This will hint that we are trying to make sure people are utilized. Like the manifesto would say, it is important to make sure people are utilized but it is more important to get stories done.

Sometimes team members ask for a swimlane per developer. This tells us that people really care only about what they need to do and not about the team. This brings us to the next item:

Story Assignee

Almost all tools allow one person to be assigned to a story. (Leankit allows many). If you want to assign more people you can use subtasks. However, we already discussed subtasks and the conclusion was quite clear.

We will usually need to assign more than one person. In many places, at least one developer and one QA will be assigned. More than that, we will be happy if people can swarm on stories – having several people working on one story is fun and contributes to teamwork and thus very effective.

So, what do we do?

Many tools allow the addition of custom fields. For instance, Jira. I usually recommend clients working with Jira add a custom field called “assigned team members”. The field type should be multi-select. You will need to manually add the list of all team members. Once you do that you ask the tool to present the information on the card on the board and suddenly – voila! You have a strong scrum board where you see the people involved in every story. That’s great.

Last but not least – Columns

Most tools start with the standard “To Do – Doing – Done” columns + a backlog. (read here about the critical difference between backlog and to-do). That’s great! Why touch it? Please don’t.

Many teams will add a “Test” column. And a “pull request” column. And there are more.

The problem with these additional columns is that they are good excuses for things getting stuck. If there is a “dev” column and a “Test” column it means it is really all right to finish dev (I’m done!) and QA can be done later. Reminds you of subtasks? correct, it is similar.

If the sprint is only two weeks long and stories are short, there should be no reason for these additional columns. Just get done with the story – and please no stories! Remember we already have the names of all involved people on the card – just get it done with.

Conclusion

A scrum board should be very simple. There is a list of stories to do. Some are in progress, some are already done. We know who is working on what. That’s it. Don’t let fancy features distract you.

You may be interested in one of our Agile Up! workshops where we help you use popular Agile ALM tools such as Jira and TFS more effectively.

Subscribe for Email Updates:

Categories:

Tags:

RTE Role
Product Ownership
An Appreciative Retrospective
Product Management
SAFe DevOps
Advanced Roadmaps
Agile Games
Scaled Agile Framework
ALM Tools
Continuous Deployment
Agile Mindset
Frameworks
Agile
Hybrid Work
Effective Agile Retrospectives
RSA
Agile Product Development
Applying Agile Methodology
Kanban Kickstart Example
ARTs
Achieve Business Agility
Legacy Code
The Agile Coach
Agile Outsourcing
Scrum Master Role
Engineering Practices
Lean Startup
Kaizen Workshop
Agile Contracts Best Practices
Spotify
Agile Marketing
AgileSparks
Lean Agile Management
Tips
Manage Budget Creation
AI Artificial Intelligence
PI Planning
Portfolio for Jira
SAFe
Lean Agile Organization
Lean and Agile Principles and Practices
ART Success
Scrum.org
Agile in the Enterprise
Kanban Basics
lean agile change management
QA
Software Development
A Kanban System for Software Engineering
Professional Scrum Master
Implementation of Lean and Agile
Certification
chatgpt
Entrepreneurial Operating System®
Risk-aware Product Development
BDD
Sprint Planning
Limiting Work in Progress
Scrum Primer
LAB
Self-organization
PI Objectives
Release Train Engineer
Agile Development
Nexus and SAFe
Agile and DevOps Journey
Program Increment
SPC
DevOps
Implementing SAFe
The Kanban Method
Introduction to Test Driven Development
Scrum With Kanban
Kanban 101
Atlassian
Jira
Agile Testing Practices
Rapid RTC
Releases Using Lean
Pomodoro Technique
Scrum Values
Agile Project
Continuous Improvement
Atlaassian
TDD
Agile for Embedded Systems
Nexus vs SAFe
Lean Agile Basics
Software Development Estimation
Video
Continuous Delivery
Risk Management in Kanban
System Team
System Integration Environments
Tools
Quality Assurance
LeSS
Lean Agile Leadership
Value Streams
Kaizen
ROI
Agile Community
Enterprise DevOps
Perfection Game
GanttBan
Managing Projects
Slides
Nexus Integration Team
Coaching Agile Teams
Agile Basics
speed at scale
POPM
Agile Project Management
Test Driven Development
RTE
Lean-Agile Budgeting
Covid19
Jira admin
Scrum and XP
Agile Israel Events
Lean Budgeting
Agile Games and Exercises
Lean Agile
Planning
Agile Product Ownership
Sprint Retrospectives
Change Management
Scrum Guide
Certified SAFe
LPM
Business Agility
Sprint Iteration
Agile Risk Management
AI
Professional Scrum with Kanban
Agile Exercises
Agile Techniques
Lean Software Development
Development Value Streams
Elastic Leadership
Legacy Enterprise
EOS®
predictability
Presentation
Agile Release Planning
Nexus and Kanban
Professional Scrum Product Owner
Continuous Planning
Managing Risk on Agile Projects
Principles of Lean-Agile Leadership
Daily Scrum
User stories
Lean and Agile Techniques
Accelerate Value Delivery At Scale
Scrum Master
Reading List
Artificial Intelligence
Team Flow
Agile Delivery
Process Improvement
Operational Value Stream
ScrumMaster Tales
WIP
Agile India
Story Slicing
Nexus
Large Scale Scrum
ATDD
Agile Program
Games and Exercises
System Archetypes
Agility
Kanban Game
Risk Management on Agile Projects
Systems Thinking
NIT
SA
Agile Release Management
Lean-Agile Software Development
Jira Plans
Built-In Quality
Introduction to ATDD
Acceptance Test-Driven Development
Code
Keith Sawyer
agileisrael
Continuous Integration
Webinar
Lean Risk Management
IT Operations
What Is Kanban
SAFe Release Planning
Amdocs
Scrum
Agile Assembly Architecture
Jira Cloud
Agile Israel
Iterative Incremental Development
ATDD vs. BDD
speed @ scale
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart