Pausing Work

No team is immune to the unexpected. Sooner or later, a large project will land on your desk out of the blue and a shift in focus seems inevitable.

What should you do with your in-flight work?

Epics & tickets are an abstraction

A sign of well-factored epics & tickets is how simply it explains what it achieves. At both levels, they hide the complexity of the work involved under an easy-to-understand title & precis.

As we’ll see, that can be an invaluable simplifying force.

Tickets

Actually working on most tickets involves many decisions & nuanced implementation considerations - but at the end of the ticket, your team don’t have to think about that. For most purposes, the ticket summarises the work well enough.

You could see the ratio of the ticket (being small & simple in scope) vs its implementation (necessarily much more complex) as a measure of the complexity a ticket hides - as its Kolmogorov complexity, if you like.

In my view, a ticket is typically 10x simpler than its implementation.

Epics

The very same principle applies to epics - where an epic is a collection of tickets that defines a deliverable chunk of business value.

An epic’s title & description hides the complexity of the underlying tickets, which in turn hide the complexity of their implementations.

Again, an epic is often 10x simpler than the tickets that implement it.

The price of return

Pausing work means, naturally, unpausing it later on. You have to pick up where you (or a team-mate) left off.

You can probably see this coming, but how easy this is depends on where you paused.

Returning to a half-finished epic & picking up the next ticket often doesn’t require you to understand the fine details of the previous tickets implementations. Understanding what they achieved is enough.

Returning to a half-finished ticket, on the other hand, means re-immersing yourself in those details. That comes at a far higher cost.

An order of preference

And so we return to the central question - when a surprise project hits, what should you do with your in-flight work?

When this happens to me, I seriously consider each of these options in order. I only progress to the next option if I’m convinced that the current option can’t be achieved:

  1. Complete the epic anyway. Some projects sound urgent, but can be delayed to some degree. If you’ve factored your epics well (i.e. as small as possible), this may be a real option.

  2. Complete the ticket, at least. This is often the sweet spot. Agree to the change in direction, but wrap up your in-flight tickets well & neatly first.

  3. Leave pause notes. If you really can’t do 1 or 2, then you’re in the worst spot you can be. The engineer should write up short & good pause notes for them (or a team-mate) to return to.

A final note on factoring

These benefits hang on epics & tickets being well factored, and their implementation being clean (i.e. without engineers leaving un-tracked loose ends as they implement the ticket).

If your team is struggling to see a benefit in closing tickets or epics out vs pausing them midway through, it might be worth asking if those aspects of your work can be improved.