(special thanks to Deepa Joshi for her input!)
I introduced the concept of thin vertical slices for work breakdowns (WBD) in my last post but the idea is by no means new, and I didn't invent it; thin vertical slices have been the state-of-the-art for work breakdown (WBD) for decades. People often don't spend time studying the state-of-the-art though, and they're more comfortable breaking things down along more natural boundaries, so a lot of teams don't actually break things up along vertical lines. I think ignoring this best practice either hurts or dooms a lot of larger software efforts though, so I'd like to just go over the subject again here, even though this a pretty well-trodden concept.
Ultimately each piece in a WBD needs to have certain properties in order to really meet our goals. Those properties are Vertical, and Thin. Let’s dig into them:
Breaking things down along vertical lines where “Working software is the primary measure of progress” gets us both Visibility (true visibility!) and actual Value Delivery. Also if we’re succeeding at visibility and value delivery regularly, we get a feeling of momentum for free, and so Motivation is easy to maintain as well.
This can be hard, because it means a particular piece of work may need different developers to make sure you tackle all the necessary horizontals or components in it. That’s fine! Multiple people can coordinate around a single piece of work. That’s the price we’re willing to pay to ensure Visibility, Value Delivery, and Motivation.
Now if you manage to break everything down vertically, you can actually slice the work into ridiculously small pieces and enjoy completing things continuously all day long. That’s really energizing and people watching the progress are generally getting a very real (and impressive) view of what’s happening and how fast things are moving.
More importantly, breaking things down into smaller pieces that everyone agrees on is the best way to get everyone’s more-precise agreement on what we’re trying to do. The more pieces there are, the less chance that there’s some large hidden detail that we disagree on. Of course, once you get started the plan tends to fall apart a little bit (and sometimes a lot), but the discussion and documentation of the plan tends to still be valuable because it creates alignment around what you’re trying to do in increasing amounts of detail. That alignment will be invaluable for recognizing when the plan isn’t on track and how to fix it.
There is a balance to maintain as well. It is possible to over-define a plan; if something is trivial and multiple possible solutions are roughly equivalent, planning every detail out can yield diminishing returns. Planning itself takes time. If your planning activities are not significantly reducing risk anymore, you can stop planning and get to work. If you’ve ever been on a team that debates for more than 30 seconds about how to prioritize a typo fix, you know the pain of over-planning.
Slicing your work into small pieces also makes it easier to estimate. Small estimates simply have less error in them than larger estimates. Also if your pieces are small enough, you can just count how many you tackle in a week to get a rough estimate of when you’ll be done.
It’s worth noting that some WBDs will be hard to do comprehensively because of unknowns. If you break things down into small pieces, it’s likely that they drive out many pressing questions / unknowns. It’s totally okay to create work items for experiments, prototypes, research, etc that may affect the direction of the rest of the work. They may or may not have the same definition of done as usual production quality software because the goal is learning or derisking and not user-value.
For example, if you’re not sure how much work something is, and want to choose a different solution if it’s really expensive, you might want to create a separate timeboxed piece of work solely for that investigation, eg “Hey I need 2 days to evaluate some libraries to see how hard that is”. When the timebox expires we hopefully have an answer that we can work with, or we can decide if we should do another timebox. A few subsequent failures of a timebox to yield our answers is itself an interesting data point -- maybe this thing is just more complex and expensive than we’re willing to take on. Or maybe everyone agrees on more timeboxes still.
In general, activities like these that make the plan clearer and help us derisk our efforts are worth doing first and in order of risk so the plan gets clear as quickly as possible and the work gets more and more straightforward.
Alright! Now that I've talked ad nauseum about the pieces of the WBD, it's time to talk about the properties of a good WBD as a whole. The next and final part will get into that critical and rarely discussed aspect of WBDs.