I’ve been checking out a number of teams and what their workloads look like. I’ve of course worked on more than few with completely disparate practices and policies. Some where really good at making great progress and others were absolutely horrendous. I’d argue one team actually went backwards in progress more than a few times. Suffice it to say, I’ve seen a whole lot of the bad and a fair amount of amazing teams. I’ve been fortunate in doing so as it really helps to have a solid perspective in both arenas.
To summarize, it’s nice to know when the ship is sinking and when the ship is sailing full steam toward the destination!
Quick context: I’m generally referring to a Product Backlog and or a Sprint Backlog.
Work in Progress Versus Backlog
Today I got to thinking and I realized I need to keep things in perspective. Especially, when thinking from the CTO perspective, about what I need to do versus what the rest of the team needs to do. As I slowly build out a team the focus from code to vision comes into stark contrast.
I started to ponder a very tactical concern. When and how does one manage their backlog without it becoming waste within the team that’s actually doing the work? How does one manage team buy in without getting them burned out thinking about higher level, often changing problems? Does one force the backlog to just not change or does one actively prune the backlog at each work effort? Why not just keep things active, forget the backlog, and build up what needs done at the beginning of each work effort? But at the same time ensuring they have vested interest to the actual high level architectural and design of the software they’re building?
These don’t have immediate and straight forward answers, but here’s a few thoughts based on experience and a good idea about what may or may not work.
- Backlogs are great for brainstorming. But they shouldn’t be set in stone.
- Backlogs should be flexible, but they shouldn’t be so abstract and flexible as the work never gets tackled.
- Backlogs shouldn’t be used to store every single wish list item. A backlog should stay active from many perspectives, to maintain its relevancy but also not to damage morale.
But are these things achievable with a backlog?
Backlogs
Backlogs are great if they’re used for brainstorming and determining the way a product is moving. They can be used among the leadership to determine, mixed in with a good dose of marketing information and company mission, the direction of the efforts of the company. However, I have seen far to many times where the actual team of developers that is working to build the product just has their time wasted when leadership brings in a backlog and says “pull tasks from this” or “pull your stories from this”.
Why do I feel this might be a waste? Because most of the backlog, based on most development teams, never actually gets completed. Most of it never even begins to be worked on. I’ve seen it happen, heard complaints to no end, and seen teams spin out of control.
The backlog ends up being a list of things that will be circumvented until the next sprint or call to action. Then at the end the backlog will be reviewed, a bunch of things will change, a bunch of other things will be added to the backlog, and the list of things to work on for the next iteration or sprint is created while actually ignoring the original backlog. This happens far too often.
So my question is, where do you break out your backlog? How do you keep a backlog useful on your team? Do you even use a backlog? How do you encourage brain storming versus just tossing things in a backlog, only to just decide what to do next based on what was just done? How does one manage work in progress (WIP) of the backlog versus WIP of the day to day stories and tasks that need completed?
I’ve just been pondering this lately and would be very interested in seeing some other’s thoughts. -Cheers