• About us…

  • The archives

  • RSS The Gaming Session

  •  Better and faster with IPv6

  • ipv6 ready

Thinking in zots

While known under a variety of different names in different businesses and industries over the last decade, the ‘zot’ is an increasingly popular business and workpower metric, particularly in software development.

While the zot is a highly variable sort of unit, its relationship to overall development costs and resources is actually quite specific.

A zot loosely refers to the amount of work, time, money and team resources required to produce something, usually a software feature or a bug-fix. Development of a bug-fix, for example, requires time from a developer, regression testing, QA resources, and sometimes additional commissioning resources (particularly where a bug-fix might require schema changes in a database, format changes in data-files, or even changes to an established API).

The core notion is that a zot spent on one thing simply cannot be spent on another. Once you’ve spent the zot, it’s spent.

If a developer spent eight hours fixing a bug, you can’t go back and use that time on feature development. If QA spent 90 hours testing a feature, that time is not available for QA on a bug-fix, or on any other feature.

Zots, of course, come in different classes – there are developer zots, QA zots, Web-development zots, system administration zots, policy and management zots, marketing zots. Part of the usefulness of thinking in zots is that it shows up bottlenecks in your processes.

If systems administration don’t have enough resources, they can’t deploy server-side features and bug-fixes as fast as they’re coming out of the rest of the pipeline. If you don’t have enough QA resources, things aren’t getting tested fast enough. Wherever the bottleneck is, you have an overall lower number of zots available, and you have staff and resources going idle.

So, while an individual department might think in zots, from a project management perspective, zots are an end-to-end resource measurement, and as a tool for highlighting resource contention.

If your release cycle is quarterly, you might decide that you have, overall, 10 zots to spend for the quarter. Development leads then triage work into zots (or parts of zots), and policy managers decide which work is going to be attempted for the release.

Half of your zots for the cycle might go to bug-fixes, and the other half to features. Other sections of the business might be able to work on content, or the Web-site or marketing, but those might be an entirely different pool of zots.

Two weeks in, and a particularly nasty bug shows up. You’ve got two practical choices: either ignore it, or throw some things out of your schedule in order to free up enough zots to get it fixed. Why not add more staff? Adding extra hands almost always costs zots in the current cycle. You don’t get the benefit of additional staff until at least the next cycle.

Not unless you’ve got a level of organization that not even most Fortune 100 companies demonstrate, anyway.

The zot system works well if you’re a writer, too. Divide your day up into an arbitrary number of zots. For each article, story or novel you can estimate a number of zots in research, in actual writing, in editorial – all based on length and type.

It allows you to estimate how much work you can get done over a period, and how much other things cut into that process. Once a zot is used, its gone, whether you spent it writing, researching, or getting the car repaired.

Thinking in zots generally works out a whole lot better than thinking in time for individual tasks, because zots are generally used to include things like overhead, task-switching, and time waiting or involved with meetings or third-parties. In short, the zot is a unit of accomplishment, not merely one of time.

Got a news tip or a press-release? Send it to news@taterunino.net.
Read previous post: