|
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.
|
{ 2008 09 29 }
Eric Landes | 30-Sep-08 at 9:21 am | Permalink
Corey, you don’t say anything here but maybe this was in a previous post? In your system are you also looking at value to the business of the feature? I know we talked about this on the real options list, but I believe putting weight in your feature for business value would also be helpful.
Corey Ladas | 30-Sep-08 at 10:10 am | Permalink
Business value is another kind of estimate. I’m assuming that all such information is encoded in the “market price” of the feature, as expressed by the distribution of votes cast.
Eric Landes | 30-Sep-08 at 10:54 am | Permalink
So you are trusting the wisdom of your stakeholders on this. Maybe I need to be more trusting! I want to force that information on the feature, because I don’t feel that happens at a feature level currently for my group.
Being an internal shop, that might be different than someone developing commercial software. I am proposing that we force some type of Business Value estimate on each feature on submission. Thoughts?
Corey Ladas | 30-Sep-08 at 11:03 am | Permalink
If I felt like business value was under-represented, I would either change the composition of the voting committee in favor of consumer stakeholders, or change the allocation of votes in favor of consumer stakeholders.
Exposing value estimates may have educational merit beyond its decision-making merit. I would tend to think of that as a separate problem, and I might encourage (but not require) stakeholders to share the reasoning behind their votes.
Olav Maassen | 07-Oct-08 at 9:22 am | Permalink
To me it sounds very much like (forgive me for using this word) democracy. The big problem I have with using democracy in systems is the majority dictatorship.
In your example this can happen for instance when the voting committee has a size of 7 and 5 members always vote the same and inspect the board daily if not hourly. The other 2 members have no way of influencing the priority.
Assuming everybody is equal, this situation would be unfair.
To prevent this from happening give everybody an amount of votes per time unit. Let’s say 1 vote per 2.5 workdays. The voting rules stay more or less the same with only one change:
votes are lost when the item gets picked up to work on.
This allows the silent minority to accumulate points on a story they feel is important while the majority still gets to pick most stories.
I could elaborate more on this, but the textbox is too small
Corey Ladas | 08-Oct-08 at 12:02 pm | Permalink
Hi Olav,
I agree that such a durable coalition in a multivoting scheme would be dysfunctional behavior. I would consider the case you present as a failure mode. Somebody would need to be responsible for seeing it as such and proposing a remedy. Do you think that adding a chance element would help?
I have to say, I like adding your time element to vote allocation, especially since we’ve already added a new time element to classic multivoting. Indefinitely repeated games often have different characteristics and equilibrium strategies than one-time games.
Corey Ladas | 22-Oct-08 at 11:59 am | Permalink
Whoops! Looks like the spam filter might have whacked some legitimate comments. Profuse apologies if I lost your comment.
Corey
Greg Starling's Agile Software Development Resource » Kanban Board for Lean Software Development | 25-Oct-08 at 2:59 am | Permalink
[...] backlog can be changed at any time by the stakeholders (Corey Ladas has a great article on using perpetual multi-vote to schedule this [...]
Multi vote Kaizen board « Lean and Kanban | 16-Apr-09 at 1:54 pm | Permalink
[...] multivoting the team can vote on which item is the next highest priority to be pulled once a slot becomes [...]
Chad Albrecht | 13-Jul-09 at 12:02 pm | Permalink
To speak to Eric’s point a bit, I think we should always evaluate features in terms of their dollar value. If we are to use ToC and Throughput Accounting to evaluate productivity then we must always think about our activities in terms of ‘The Goal’ which is to make money. I’ve documented this in a bit more detail here:
http://blog.chadalbrecht.com/p.....tures.aspx
On you concept of multi-voting, I would be interested in exploring the evaluation criteria that is used by each voter.
Thoughts?
Corey Ladas | 16-Jul-09 at 8:38 am | Permalink
There are value, cost, and investment factors for every feature. Different participants have insight into each of these. Voting and auction schemes might allow the participants to contribute their particular expertise at a lower cost than a more analytical or negotiated approach. For example, a design improvement might not look like a “feature” to the customer, but it reduces the cost of new features in the future. The sales guy won’t see that, but the architect will. So sometimes the architect should get his way, and we want a way to let him get his way occasionally for least fuss and least cost.
Personal Kanban: Tangible Tasks Produce Prioritization | Personal Kanban | 26-Oct-09 at 2:02 pm | Permalink
[...] and Eric Willeke asynchronously put their heads together and came up with Perpetual Multivote. This process recognizes that good decision making has both temporal and social components. As [...]
Multi-Voting « Steffen Prohaska | 27-Feb-10 at 8:10 am | Permalink
[...] Perpetual multivote for pull scheduling [1] [...]
» Kanban Board for Lean Software Development - Greg Starling's Agile Development, Gen Y and Social Tech Resource | 21-Mar-10 at 11:28 am | Permalink
[...] backlog can be changed at any time by the stakeholders (Corey Ladas has a great article on usingperpetual multi-vote to schedule this [...]
Kanban – FAQ « Managing Software Development | 20-Nov-10 at 9:03 pm | Permalink
[...] to make a decision. I found an interesting link where he talks about the prioritization of MMFs. Perpetual Multivote What kind of projects are best suited for Kanban? With my current knowledge, i feel that the [...]
Fair Process and Agile – going further than the Scrum Team | Yeret on Agile/Kanban | 22-Feb-11 at 11:54 pm | Permalink
[...] Backlog Prioritization among a Product Management team (btw this is related to Perpetual Multi-Voting but don’t forget to add in a [...]