deadlines, timeboxes, priorities

why things are kind of awful and perhaps a way toward away from awfulness

tldr; Often, we’re working to a deadline that should be a “delivery timebox”, and our narrow focus on “outcomes” often blinds us to the ways we can get more smarter without breaking everything.

My theses:

• We assign deadlines because we’re worried we won’t get some more distant need serviced in time.
• We prioritize in a style that’s conceptually too strict and too coarse grained in time, which forces us to make everything “high priority”. When everything is high priority, nothing is.
• The soft work people often do gluing things together has value and most people know how to prioritize it against other normal tasks, but can’t do so facing deadlines.

Time boxes are thought of as part of scrum practice in some circles, but only at the whole sprint level. I’d suggest they’re more useful at a smaller scale, often to replace items conceptually thought of as deadlines.

Imagine that you’re working on a project and the product owner pulls out the Steelcase® Mobile File Cabinet with Cushion Top beside your desk and says “I’m counting on you to deliver Low Priority Customer’s special features by next tuesday, but make sure to get High Priority Customer’s Full Sprint Issue done too, they’re much more important”. Maybe like me, instead of taking effort to imagine, it’s taking you much more effort to forget. Puzzling for most of these situations is exactly how long Low Priority’s feature has been patiently waiting at “Medium” priority in your “big Jira of failure and regret”. Why wasn’t this worked on in the 3 whole months between when Low Priority became your customer and when they wanted their thing? Because it wasn’t high like everything on High Priority’s list. Now it’s high because it’s almost comically and disastrously late, and still possibly worth a lot of money. It can easily be the case that all told, a full year of dev time would be paid for by the delivery of Low Priority; High is simply worth _more_.

Regardless, there’s a lot here, so let’s think about this request and what it means. Unfortunately there’s nothing you or I can do now, or even could have done at that moment, but I believe there’s something the next iteration of similar atoms coming together in a similar configuration can do in this infinite universe.

• High Priority Customer is and has been more important than Low Priority Customer, but both are important enough to want to work on.
• Low Priority has been blocked for months while things that were far from critical were delivered for High Priority.
• At some point, the product owner decided that there was too little time to continue labeling Low Priority’s task as “Medium” and jumped it to “High” and now wants to cheat by promising your time to both Low and High.
• Note that even if you’ve been promised some incentive to balance this effort, I’ve only _ever_ seen this promise delivered upon in games, where people crunch for literal years on end.

So if you could just Dr Strange your way to a better world, what should you do?

Enter: The “delivery timebox”.

Timeboxes haven’t been specialized in the scrum literature I’ve seen since every sprint is considered by itself to be a “delivery timebox”, but I’m going to make that explicit here to separate it from an “experiment timebox”.

An “experiment timebox” is where you try an experiment or make an honest effort to do something and the deliverable is the reported _experience_. A race can be an experiment timebox because you’re trying to cross the finish line faster than your last time, and the outcome is the amount of time. If your training is making you faster, it gets better, if not it might get worse. Ultimately, you’re not going to slow down or stop training regardless, but you might use the result for guidance. Similarly, timeboxing an experimental feature in software is similar. The outcome will inform decisions like “is this important enough to soldier through?” and “can we do it cheaply or should we buy it?”

A “delivery timebox” is a little sprint just for one or a few. The goal is simply to improve something in the scrum conception “potentially shippable” into something better and still “potentially shippable”. You don’t need anyone to kill themselves (hopefully) over all the features (you won’t get them anyway by waiting until the last week and then hot potatoing the whole thing on somebody). If you’ve got time, then you don’t need to set any deadlines yet, and you can still set “aspirational” goals for these experiments to see what’s left in the hopper, in fact it’s desirable (in my opinion) that a “delivery timebox” has about 1 1/2 times the amount of stuff in it that it actually needs, to make room for all outcomes to have some meaning. Too little and it just gets done without saying a lot; too much and you’re just going to encourage a feeling of hopelessness. There’s no point in picking up the second grain when the task is to move a mountain.

Going back to deadlines, why wasn’t this assigned earlier? Most likely because

• There are other things being worked on that have their own deadlines (otherwise you could move them)
• Being constantly at capacity, the product owner was hesitant to assign even more deadlines on even more work for an extended period, deciding to just have a high stakes “make or break” at the end.

Why do we use deadlines this way though? What’s the purpose? Often it’s to “show improvement”, “justify budgets” and “take to the board meeting”. While there’s no getting around a situation where a single URL will be on a super bowl ad, how often is that really the reason we have tight deadlines? Aren’t most of these just as well served by “delivery timeboxes” as well, leaving deadlines for the really important things?

If you’re a product owner, make room, not with deadlines, but with delivery timeboxes. Spread the work out so you can see what’s going on and so that, worst case, the person you finally do put a deadline on in the last week can be adding the last features, not the first. Use deadlines where there’s something external at stake and delivery timeboxes when you want to show something new to the board. Retain your capacity to respond to real emergencies _and_ avoid urgency.