Here is a story board to consider. Is it healthy? Is it being well-operated?
New scrum practitioners may say that it looks great if that’s the first day of the sprint, but indicates serious problems if it looks like this on the last day or two.
More experienced Kanban users might suggest that it’s off to a rather poor start.
You are running your board backward.
Too Much Starting?
People new to kanban boards tend to empty the leftmost column as quickly as possible. It’s completely understandable (especially in cultures where we read left-to-right) but this practice has some serious risks.
Work-In-Progress dilutes team effort.
Having a huge backload of work can create a sense of hopelessness in people and push them into the “what the hell effect.” That state cannot be good news for your project.
Studies suggest that people are more energized and motivated by accomplishment. This suggests that even on a human level, it is better to complete jobs than it is to start more jobs which will remain unfinished for days or weeks.
Additionally, the studies are in on the topic of multitasking. Even without all the costs associated with branching and merging, the costs of individuals switching between jobs may be worse than the cost of delayed features. Multitasking may cause damage to the human brain.
Decline of Productivity
Starting many jobs at once encourages individuals to work alone instead of collaborating. There are many things to do, and since one person can only focus on one thing at a time, the only way to make progress on all of them is to divide the work among people, right?
We have learned that we get better productivity by working together to complete/close a story quickly. Finishing stories also creates motivation, preserves emotional resilience, and leads to more frequent integration and feedback.
Options
Work in progress robs us of options.
If a story is not started, the business can choose to defer, drop, rework, simplify, or split the story with no serious cost or consequences. This allows us to steer product development.
Once a story is finished, it is a “done deal” and can be delivered.
What about stories in progress?
- Not finishing the story can leave code in a partial state and can delay release.
- Dropping or deferring the story requires undoing work and demoralizes developers.
- Re-working the story has roughly the same disadvantages as dropping it once significant progress has been made.
- Work in progress is felt as promise debt and is subject to the Zeigarnik effect.
These issues are why some people use costly feature branching and why Scrum says that a sprint backlog is not to be changed during the sprint. It is one reason why Lean systems like Kanban limit the amount of work in progress.
We don’t think that branching, multitasking, and freezing requirements are the best answers to these problem. We believe that we get more value from evolutionary design, continuous deployment, and lower WIP limits.
Prioritize Finishing over Starting
Filling the rightmost “done” column is better than emptying the left “todo” column. We never want to be in a position where 100% of the work is 80% done.
On the other hand, if 80% of the work is 100% done, you have a qualified success.
Here is a flow we find more helpful:
- Find the rightmost column of the board containing cards with work still to be done.
- Pick one card from this column and ask your teammates how you all can collaborate to move it at least one column to the right.
- If a story is blocked, don’t skip it. Work on un-blocking it.
- Continue with the next card in the same column (if any exists).
- If some people have not yet joined their teammates on a card, move left to the next populated column.
- When everyone has work, stop. Usually you will not make it all the way to the left.
Operating in this right-to-left fashion has benefits including early completion of the most valuable jobs, easier collaboration, increased focus (decreased multitasking), and opportunities to steer with options.
Additionally, it makes standup meetings less boring.
Readers familiar with the Kanban system will recognize that it is just one short hop from here to WIP limits and optimizing lead time.
Do you see teams over-starting and under-finishing? I’d love to hear what you think in the comments below.
