The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Guidelines for priorizing features

We're in the process of planning work on our in-house SDK for the next few months, and I'm in charge of putting some order to the long list of TODOs and nice-to-haves the whole team has listed.

The priorization itself will be done as a team, but I'd like to propose some simple rating system to make it a little bit more systematic and efficient.

I've read the JoS article on priorities, and we'll probably draw heavily from that technique, but I was wondering how others go about this kind of priorization effort.

So far, my criteria are roughly, in more or less decreasing weight: effort, time-saving potential, peace of mind (for things like defensive programming mechanisms and automated tests which have no direct benefit but help you sleep at night) and annoyance-reduction (for things in the current SDK that just grate on everyone's nerves).

Catherine Send private email
Tuesday, June 19, 2007
Give each person 10 tokens to 'vote' with.  Then let them 'vote' by assigning tokens to features.  When they're out of tokens, count the number of tokens each feature has gotten.

These other criteria you call out are nice, but awfully subjective.  With 'subjective' criteria, you can quickly reach the conclusion that every feature is critical.  And once every feature is critical, you've lost any ranking between them.
Tuesday, June 19, 2007
Can you apply a business value to each work item and a size to complete it. Work items that return the highest business value and are quicker to complete go to the top of the priority list.
Tuesday, June 19, 2007
Give the tokens to your customers instead of to your employees!
Steve Moyer Send private email
Tuesday, June 19, 2007
One tool I've used is a "forced choice" of features.  Basically, we looked at every pair A and B, and said "if we only had time to do one, should we do A or B?"  (Alternately, if we could only do one first. . .)  We had narrowed everything to the top 10-20 features before we did this.

At the end, we counted up how many times each feature "won."  The feature that won the most pairwise comparisons was our #1 feature, the next one #2, etc.

I'm not sure how this would compare to Joel's technique, but it did fix the problem we were having, which was that everyone said "we absolutely have to do every feature."  And even with this technique, for a lot of the feature choices, people would say "we should do both."  But the question was "which one should we do first?"  Being forced to pick clarified in the participants' minds that there is a use for prioritization.  And the list we came up with seemed intuitively right, although none of us had been able to generate it beforehand.  Oh, and of course, everyone had their input into the process.
Michael G Send private email
Tuesday, June 19, 2007
Token approach.  I think that is called the law of subjective probability.  It is used to quantify "gut feelings" that are hard to express in raw numbers. 

The US used it to find some hydrogen bombs that fell out of a B52 in flight over Europe a few decades ago.  Instead of tokens, they team members were each given a fixed amount of play money to bet with odds.  They found all but one bomb and were getting desperate.

The betting of pilots, weathermen, scientists, etc. was summarized and analyzed.  With that data, they concentrated the search on a grid that showed the highest probability.  There it was, on the ocean floor off Spain.

So, tokens.  Yeah.  I like that.
Tuesday, June 19, 2007
"So far, my criteria are roughly, in more or less decreasing weight..."

Keep in mind that your criteria are not all encompassing and while I agree with your priorities, I suspect there will always be someone who doesn't.

Labor costs, publishing costs, "customer support" costs,  documentation costs, security, intellectual property and derived ownership issues would all also be valid criteria in publishing a SDK. For example, many of the features in the Sony SDKs were deliberately inserted to encourage the use of Sony media for storage. While I detest that decision on ethical grounds, it does make sense economically. The point is that what your users will be allowed to do with your SDK does determine which features go into it.

In addition to the various priorizing techniques suggested, I would also clearly define the veto rules up front, and in advance. For example, what happens if Legal and Marketing what the copyright to automatically show up in the finished product? That is a "feature" most developers wouldn't think to consider until late in the process.
Wednesday, June 20, 2007
Sorry, I misread the original context. Catherine is thinking of developing an SDK for internal use only? If that's the case, annoyance reduction would be at the top of my list.

Anyhow, it may be worth having a couple of managers sit in and act as referees whenever the discussion strays from the company's business goals.
Wednesday, June 20, 2007
"Benefit to the customer" ought to be the most important factor, because if all the reasons for buying the product fall off the bottom of the list then you'll efficiently build a strategically prioritised unsaleable waste of time.

"What to build" and "how to build it" are related and the available resources determine what's valid for the "what to build" question, but the people doing the building are the wrong people to make the decision as to what they're going to build.

It worries me when "ease of implementation" is considered more important than "ease of use". That says something about the team's priorities, and it doesn't say that you're building something that will be intended to be useful.

Wednesday, June 20, 2007
If you're building an SDK, I personally would strongly suggest you either spec out or actually try to build an app that consumes that SDK. That'll tell you the pain points very quickly.
Chris Tavares Send private email
Thursday, June 21, 2007
Thanks for the input! We'll probably go with a token system then. But I'm keeping the idea of pairwise comparison for sorting application features with the project managers (who are, in practice, customers of the software department, and who tend to have LOTS of #1 priorities. Also, strangely enough, every manager's project is the company's #1 priority as well... ;) )

Just to add a few precisions:

- Our SDK is indeed an in-house tool only. It's already widely in use, and we've already gone through a few phases of improvement, so we have a pretty good idea of what is still painful (even though it's incredibly better than it used to be). But since we all work with different parts of the SDK, our priorities differ.

- We have limited ressources, since most of our development time goes to developping applications that actually serve a purpose (and bring in revenue). Improvements that directly and obviously benefit an application can generally be "sold" to that project's manager. So we generally try to focus on things that make our job more efficient or less error-prone.

- There are also a couple of features which would make all of our products slightly better, and no single project manager wants to "buy" that feature (but of course, everyone will want it once it's free.) So those generally come out of the SDK budget.
Catherine Send private email
Thursday, June 21, 2007
If there is no external means of prioritizing, why not have each developer chose the feature that he, individually, wants to work on.  Each time a developer completes a feature, he can select another one from the list.  There is no need to impose a prioritization scheme if not objective priorities exist.
Wayne M.
Friday, June 22, 2007
Even though you are not a startup, I like Dharmesh's list:

The Art Of Startup Prioritization: Maximizing The Wow-To-Work Ratio:
Scott Meade Send private email
Tuesday, June 26, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz