Units of work

Blake Weyland

1. Units of work ←
2. Simplify product work
3. Simplify development work
4. Product development tools
5. Universal product tools

Product development organisations waste time organising, especially when company growth leads to constant reorganising. They principally organise two things: the people, and the work.

Work structure

Product development teams typically structure their work into ‘units’ at various levels of granularity. From smallest to largest, one unit of work could consist of one:

1. code commit - a source code version control history entry
2. pull request - a batch of proposed code changes
3. development task - a change to the software
4. user story - a new or updated software product capability
5. epic - a large user story that requires splitting
6. key result - a success criterion for an objective
7. objective - a high-level product development goal
8. initiative/theme - related work at one of the above levels.

In practice, this all varies between teams.

Variations

Different teams use different names and descriptions for their units of work. Variations include:

• method - different software/product development methods use different levels
• scope - each unit may contain exactly one, a few, or many units from a previous level
• timescale - from minutes/hours, at the top of the list, to months/years at the bottom
• assignment - a single team member, several, the whole team, or multiple teams.

Different variations (and development methods) work for different teams. And while the level of success varies, so does the level of chaos. Deliberately or accidentally, product development teams have several ways to make their work more chaotic.

Method complexity

Software and product development methods vary between teams, and their methods’ complexity tends to increase over time. Not only does your product development organisation probably not need eight levels of units of work, but it would do better by simplifying how it works by removing one or two.

But managers like to manage and plan, so long-term initiatives and themes tend to emerge. And programmers just love tidy hierarchical structures, so they rarely seek simplification either.

Tooling proliferation

Additional chaos results from something worse than too many work breakdown levels: manifesting every level you use as an artefact in some tool, e.g. a Jira issue. And when you don’t have a tool that models every level you use, you get something worse: several tools that capture 1-3 levels each.

These tools integrate awkwardly at best, with links to other tools that take too long to initially load. And tool costs typically lead to different subsets of the organisation having access to each tool. Half of the links don’t even work for half of the people.

Size variance

When some user stories require 5-8 times more tasks/effort than others, for example, the work becomes difficult to track. Inconsistent scope and timescale within one level hinder visibility and management. And that can lead to attempts to add clarity by predicting the future.

Prediction trap

Attempting to create ‘clarity’ with imposed estimation practices increases method complexity, and doesn’t actually work. Wild guessing has many consequences, but they don’t include increased clarity.

Instead, what you actually know, such as the results of discovery work, gets mixed up with dodgy predictions. And when you make predictions, you have to manage them, which means more meetings to explain how the predictions change as their wrongness matures. Good luck with that.