I'm halfway through this week of working through my too-high WIP. So far, I exposed my WIP and talked about how I planned to use continuous flow in Part 1. Part 2 was about cycle time and using Cost of Delay to make easier decisions. Today is about why I don't use a real backlog because I get interruptions. I want to make those interruptions easier to manage.
First, my WIP status:
- 4 presentations still (no change from yesterday)
- I finished all the video editing for the writing workshop. At some point today, I plan to upload the videos to teachable. Because there's more work to finishing the workshop, I'm sure I will not finish the workshop today. But I can get ready to finish.
- I still want to write more in the book. (Zero words yesterday and the interruption below was the reason.)
- Fiction words for the novella. (Zero words yesterday)
- 2 columns I want to write. (Zero words yesterday.)
So, I claim to be a writer. And yesterday I wrote zero words. I don't count emails, Slack, etc. I only count words more than one person can consume.
What happened?
An interruption. This is why I use options instead of backlogs.
Why Teams Use Backlogs
I don't have just one product for my business. And I'm not a team working on just one feature set or a product. I'm one person working on everything I need to do for my business.
Many teams find benefit in using backlogs to determine what to do now, especially if they don't use continuous flow, as I do. Backlogs can be valuable in these circumstances:
- The team does not have interruptions in the middle of their iteration or planned work.
- While the team might want a look ahead at the future work, the backlog focuses them on the work right now. (Often for two weeks at a time.)
- Backlogs help the managers stay out of the team's way. That's because the manager can look at the backlog and know what the team is doing.
Backlogs can serve useful purposes, especially when the team does not have interruptions.
However, some teams (and organizations) use backlogs as if they are roadmaps, with every possible idea in the backlog. Those backlogs end up as too bulky and too full of everything. The organization needs to Clean Your (Their) Backlogs.
And, too often, the roadmap does not change, so the backlog stays in place, as if it is a petrified tree, glowering over the team and their work. The team becomes a slave to the backlog.
I stopped using large backlogs for my work years ago. That's another reason I use continuous flow.
How Continuous Flow Helps Me Decide
I experience interruptions all the time. Almost every day, even now, when many people are taking this week off from work. That's the big reason I don't use backlogs.
And, yesterday, I experienced a future-client interruption. I've worked with this leader before. Did I want to work with her again? Of course. And she's now at a new organization with a new vendor onboarding app.
I chose to interrupt myself and spend the almost 2 hours finishing my profile on this new application. I knew that would reduce my intellectual capacity time. However, I reviewed the Cost of Delay again for all my work. I decided I was close to done on the videos that I could spare the time to spend on getting my information into this new app.
My Cost of Delay calculation: Making it easy for clients to hire me takes precedence over other work. They can't give me a purchase order if I'm not in their system. Those purchase orders are much larger sums of money than an online workshop or revenue from a book.
So I made a note of where I was on the videos (leaving my work clean), and spent time on the app. I expected to spend an hour and it took almost two hours. Fine.
If I had a backlog, I would have had to put the item on the backlog and create an urgent column, so I wouldn't forget it. I might or might not have finished the videos anyway.
But I would have created more WIP for myself. That's because when I used backlogs, my work was bigger.
Some Backlogs Hide the Size of the Work
When I used backlogs, my work items were larger. I see this in most of my management clients and at many of my team clients. Somehow, the backlog discourages “how little” thinking. I don't understand why this happens, but I see it all the time. I'm sure it's a human thing.
However, when I switched to continuous flow, I have a different approach to my planning and sizing of my work:
- I have a yearly strategy with the answers to who I serve with which products and services. As part of that strategy, I have interim deliverables. For example, I have a deliverable that I just put on my yearly plan: “Get some kind of a store on my site in 2022.” That's it.
- I always have repeating outcomes, such as “write all 3 newsletters every month,” and “At least one blog post in each blog every week.”
- I put all that plus the work I agreed to in my “options” list. All of these options are outcomes. Although, I often have interim deliverables, such as I have this week with the workshop videos.
When I still used a backlog, I would write something like this: “Draft 1 of writing workshop.”
But that item is huge, way too big. I'm not sure I could finish the writing workshop even if I spent all week on it.
And, I don't want to spend all week on it.
When I moved to continuous flow, I separated out the prep for the videos, recording the videos, uploading the videos, checking and rechecking the dates for the drips, and then finalizing all the various pages, pricing, etc. The marketing for that workshop is also separate.
Most of those deliverables are internal deliverables, but I can see my progress. I can right-size my work.
Collaboration Helps Remove the Need for Backlogs
If you work in a team, you might need backlogs to track all the work in flight, your WIP. If your team limits its WIP with pairing, swarming, or mobbing, you don't need a backlog. You need a “What's next” item and a list of options.
Since I collaborate with myself (!), I only need to think about a few things at a time. I focus on what I'm doing now. I can always change “what's next.” And I maintain that list of options.
One of my clients uses a board similar to the image at the top of this post. IMNHO, they have way too many decisions to make on a regular basis. They have to decide what goes into the sprint (the Ready) column. They have Today, and they have Urgent. They need team (including the product leader) agreements, and management agreements, and support agreements.
That's a lot of decision-making without a lot of ease for their daily work.
I've been nudging them to reconsider their backlogs and move to continuous flow. They're thinking about that. One of the team members said, “But our Ready column will either be huge or really small.”
Exactly. Huge if you've done too much work in advance, or small if you're working just in time.
Options, Not Commitments
In my recent Roadmap series and in Manage Your Project Portfolio, I wrote about options instead of commitments. (Managers need to commit to teams, not ask teams for commitments.) The more we use option language, the more we realize how easy our decisions might be.
Okay, I've got to get back to work. My WIP isn't going to decrease on its own.
The series:
- How I Manage My Product Development: Ease with Continuous Flow (Day 1)
- How Cycle Time and Cost of Delay Makes Product Development Decisions Easier (Day 2)
- Easier Product Development Decisions and Why Backlogs Might Slow You Down (Day 3)
- Focus on One Internal Deliverable Allows Me to Work Down My WIP (Day 4)