September 2008

Perpetual multivote for pull scheduling

If we’re going to schedule one work item at a time, then we have to have a reliable method of picking the next item. Sometimes the work has a natural order and more-or-less picks itself. Other times, we have a backlog of things to choose from and have to make a decision. This is not so much a prioritization problem as it is a filtering problem. We don’t care about the 30th priority feature in the backlog. We only care about the 1st priority feature. That should make it more a matter of eliminating things we’re not going to do now, rather than sorting things that we may do someday.

The priority also has to be “always live.” In our system, development capacity can free up at any time. When it does, the next candidate should have been previously selected so that the team can get right to work. That means we’ll have to make frequent updates to the selection process. If we’re going to do this frequently, it has to be inexpensive. Consensus building is expensive. My goal is to do this with no estimates and no meetings.

My first proposal was to create fixed-size priority buckets and make work items compete for space in those buckets until they rose to the top. I labeled this idea the “priority filter,” and I’ve been using it for a few months. After some discussion about it, I asked for a Digg-like or prediction-market-like scheme. Eric Landes proposed some kind of multivoting system. Then Eric Willeke chimed in, and I started to focus on a new concept, which I’m calling perpetual multivoting. I’ve participated in a lot of multivotes, but I’ve never seen a continuous multivote. I don’t know if we reached a perfect consensus, but this is my current interpretation:

  • A “voting committee” is selected, representing a fair cross-section of stakeholder interests – producers and consumers. Each voting member is assigned a color and an allocation of votes.
  • The voting members can add an item to the selection backlog at any time. Backlog items are date stamped. When the list overflows, the oldest thing is ejected to make room.
  • Voters may cast or recast their votes at any time, and they may cast multiple votes for a single item.
  • When the pull event occurs, the top-voted item is immediately selected. In the event of a tie, a tie-breaker vote will be called. The votes from the selection are returned to a vote pool. Their owners are expected to recast them as soon as possible. If a pull event occurs and there are votes in the pool, the voters will be nagged.

Comments (16)

Print This Post Print This Post

Email This Post Email This Post


Why pull? Why kanban?

People with different skills have to work together to deliver product features. Don’t build features that nobody needs right now. Don’t write more specs than you can code. Don’t write more code than you can test. Don’t test more code than you can deploy.


My team builds a component. Your team builds a component. I use your component. Don’t build features that your clients (like me) are not asking for. Don’t accept my requests if you can’t build them now.

Pretty simple to describe in theory. Some subtlety in practice. A kanban is a tool, and like any tool, it is meant to solve a problem. I think kanban solves this problem more efficiently than the known alternatives.

Comments (5)

Print This Post Print This Post

Email This Post Email This Post


Options have value. Options expire.

Real options are an enhancement to, or perhaps an explanation of, the priority filter concept for backlog management.

A kanban is used to make claims against the productive capacity of some resource. If I have a kanban, I can give it to you in exchange for an object or process of real value. The value of a kanban depends partly on time. The most relevant temporal data about a kanban are:

  • time of creation
  • time of redemption
  • time of delivery

…from which we calculate lead time and cycle time. A regular kanban represents a commitment–a real claim against real resources. When a kanban is exchanged, it is with an expectation of certainty that the work order will be satisfied.

Planning decisions, by contrast, involve uncertainty about work that we might perform in the future. Work requests placed at the end of a deep backlog do not represent a commitment to deliver. Pending work requests are always temporally contextual. They can only represent current understanding and intent, and the world will change before they enter production. The longer the backlog is, the greater the uncertainty about relative priorities and lead times.

Such uncertainty is not a problem as long as we are always able to determine a satisfactory answer for what to do next. You can’t utilize more capacity than you have, and adjustments to capacity have a lead time of their own. Your plans and priorities are sufficient as long as you always know what to do next. An efficient planning process is just barely sufficient to provide that information.

The priority filter is an attempt to define a planning process that directly represents the distribution of uncertainty of pending work requests. The work requests themselves are represented as kanban-like tokens. However, a kanban as we’ve described it really only works within the context of carefully controlled queues and processes. A kanban is a commitment, when what we really need is an option. Still, the kanban is a convenient representation for visual control, so what’s stopping us from defining a new kind of option kanban for planning purposes? Nothing!

Like a real kanban, we want to encode information about the scope and value of the request, but the temporal information we need will be different. I will argue that there is only one thing about time that we need to know about our option token: the expiration date.

Placing a token in one of our priority buffers amounts to buying an option to schedule the work for production. The price of the option is set by the capacity of the buffer. The expiration date is calculated from the purchase date and a duration that is also bound to the buffer. So, the priority 3 buffer might have a capacity of 8 and a duration of 30 days. When a new token is placed in the buffer, we calculate the expiration date and the token begins to age. Our priority 3 option gives us the right to bid for any higher-priority options that become available. Availability of a priority 2 option triggers a comparison of priority 3 tokens to select one for promotion. All of the p3 tokens are ageing, and any that are not exercised before their expiration date are cancelled. A cancelled option might return to the deep backlog, or it might disappear entirely. Age then becomes a first-class consideration for competition, where a nearly-expired token may be promoted over a higher-value token that is brand new.

In this way, we work our way up the priority ladder, incrementally investing as our certainty improves, until we finally earn the right to buy a real kanban that we can exchange for the real goods or services offered by our production system. It’s only when we can afford to buy a real kanban that desire becomes demand and the lead time clock begins. If we end up getting cancelled, it will likely be while it is still cheap to do so. We’re only out the cost of our options, which should have been much cheaper than the cost of a real kanban, which we only want to buy if we’re certain that it’s for something that we want.

Comments (2)

Print This Post Print This Post

Email This Post Email This Post


Ivar Jacobsen on the future of software development practices


Comments (0)

Print This Post Print This Post

Email This Post Email This Post


E-mail It
Socialized through Gregarious 42