{ 2008 09 29 }

Perpetual multivote for pull scheduling

Corey Ladas

Print This Post Print This Post

Email This Post Email This Post

Permalink

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.

Posted by Corey Ladas on Monday, September 29th, 2008, at 5:12 pm, and filed under kanban, lean.

Follow any responses to this entry with the RSS 2.0 feed.

You can post a comment, or trackback from your site.