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

The Critical Difference Between Backlog and To Do (Kanban, Scrum)

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

When we build a kanban board to manage our work (either practicing Kanban or Scrum) we usually create a Backlog list (usually the first column) and a To Do list (following the Backlog). I’ve noticed that many times the separation between the two is artificial and people don’t always understand the critical difference between the two. I’d like to discuss it here.

The Backlog

The backlog is a list of things we think we should do, for many reasons (clients, our own needs, etc.). Moreover, it is prioritized, so things on the top are things we really really want (or need) to do while things at the bottom are probably fantasies that will never happen.

For instance, the backlog of an airport is all the flights and the backlog of a road system is all the cars that need to go somewhere. And the backlog of a development team is all the software that needs to be developed.

As stuff goes up in priority it becomes more concrete and more focused, shedding off redundant things, like a baby growing up and losing their baby fat. This process is called backlog grooming or backlog refinement. And still, the backlog is a list of things we want to do, we should do, we need to do – even the topmost items. Not more than that.

The To Do

The To Do is a list of things we decided to do now because we believe that we can accomplish them in high quality and timely manner. This is a big decision. Moving something from the Backlog to To-Do takes a lot of responsibility. You should consider it gravely. The hand holding the note, moving it from Backlog to To Do (or more likely, firmly grasping the mouse) should tremble.

Once you decide to do something, you want to do it very quickly. This is our cycle time. The shorter our cycle time is, the more focused we are, the chances for things going astray are lower, the chances for us changing our mind midway are smaller and many other good things – see Don Reinertsen’s book Product Development Flow for the full list. Mr. Reinertsen gives airplanes as an example. I’ll extend it a bit: airplanes should start boarding only when it is known that the airplane can freely taxi to the runway and then land directly without circling. Imagine how much time would be saved. And the same goes for traffic over a road. Imagine a system that could tell you when to go out of the house so traffic won’t be congested.

When the team has available capacity (or in Scrum during the planning meeting) the team makes this decision. The team decides they will do something. If they think it is not yet ready they should keep it in the backlog. Ready for what? Ready for the way the team machine knows to process stuff. The team calibrates the way they work and the stuff going into the machine should fit this. It is a matter of practice for the team to know how to better work together.

The same goes for an organization now planning to do something in the next quarter – once they decide they want to do it they should do everything they can to make it progress very fast.

Grooming

Of course, there’s a trade-off between how much you invest in an item when it’s in the backlog and later. Investing while it is in the backlog will increase predictability on one hand, but on the other hand, it will increase the number of things you do in parallel which results in less focus and more waste due to context switching. You need to find the right balance.

In a sense, knowing when an item is ready for development is similar to knowing when a fruit is ripe – read more about it here.

Breaking It Down

And what if something is really big? We can’t do it really fast, but we do it in small pieces, small pieces that make sense. We do it so that once we’re done with a piece we have something complete (even a draft) that can provide us with information on how to continue.

I found that, as I have a degree in procrastination, doing things that take very little time is a miracle. I lose focus very fast so if I want to complete something I need to complete it fast. But so does an organization, right? How focused is your organization?

Once you practice doing things very fast, in the required quality, you actually complete stuff.

Another advantage of cutting things down is that you are able to remove the redundant scope.

Mixing It All Up

The problem starts when we mix the Backlog with the To Do when things we should do somehow become things we do. People in a car want to get to their destination in the morning and immediately they start driving. Then we get congestion. Projects arrive at the company and we immediately start development. Then we get congestion.

But why does it happen? Why do we mix the Backlog and the To Do?

First, it is easier to just start. It is easier to manage. There is something you need to do and you just do it. It is easier to manage when you react. It is easier for every driver to go out of their parking and start driving rather than waiting for some sign to start driving.

Second, it feels much better to start doing things you should do. We are industrious people and when there’s a job to do we make a plan and start doing it. I remember as a kid I was told the best way to do homework was to do it the day you got it. It stands against our intuition not to start something we need to do.

We need to learn to make the differentiation between what we need to do, what we should do, what we want to do, and what we are doing, between the Backlog and the To Do. This separation will help us to focus on what we do, complete it when we need it, in the right quality, and eventually do more and better than we do today.

More to read:

The Professional Developer

Understanding the relationship between Kanban and the Theory of Constraints Critical Chain Project Management Approach

User Stories don’t belong in the Marketing Backlog

How Leaders can support and leverage the Scrum Artifacts

Agile Product Management​ (APM)

 

Subscribe for Email Updates:

Categories:

Tags:

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