Archive of Prioritization Articles

The second release of nexus went live today (build 127). It included the top features from our prioritized list published yesterday. This enabled the next use case from our first prioritized list of use cases - searching the articles. We also took this opportunity to refactor part of the user interface - adding pagination of articles and search results, and reworking the presentation of the article content based on user feedback.

In this article we look at the content of the third alpha release of nexus.

The next build of nexus starts today as our agile project continues. Let us know what stuff you think is most important for this release, as part of our prioritization.

Rolf presented a valid critique and some questions on our previous article announcing the launch of nexus. I started writing a long response, and realized it would work well as an article for analysis of our process over the last month. Here it is.

In the discussion on our article about understanding users as part of our agile software development case study, Rolf raised an interesting question about the scope and vision of having people rate articles:

I’m wondering what an ‘article’ is. Does it have characteristics? Is it just some piece of knowledge (I’d say: yes), or even just a reference to a piece of knowledge?
Is it important that an article is readily accessible from the site (that would exclude training courses, books, …)? My answer: no, even a hint for a good book or a reputed company would be of help to the personas.

Rolf

This article has a poll asking for your inputs.

One of the goals of agile software development is to deliver value quickly and iteratively. One of the most effective ways to begin the software development process is with use cases. To deliver with agility, you start with the most valuable use case, bang it out, and then move on to the next most valuable use case. How do you know which use case is the most valuable if you haven’t defined all the use cases first?

Writing Complete requirements is one of the twelve elements of writing good requirements. Sometimes, you don’t have the opportunity to finish the job, and are forced to write incomplete requirements. How would you go about doing that?

Prioritization with ROI is generally thought of as a quantitative analysis. For hard ROI, that is true. For soft ROI, it is anything but true. You have to make a prediction of the utility of the requirement or feature. That predicted utility is based on our expected utility, which is based on your past experiences. Your past experiences are reflected in remembered utility, which is a function of experienced utility. How can you know with certainty, and use that to prioritize requirements or features?

Look Ma! Me Too! The temptation to compete against a checklist can be overwhelming. When we have a competitor who provides 100 of this or 200 of that, it might seem smart to offer 200 of this and 300 of that. We’ll be better off if we focus instead on creating the other thing. The best way to compete is to valuably differentiate our product, not outdo our competition.

More is better features are just that - more is better. But more of the same old thing is worth a whole lot less than some of something else.

The wisdom of crowds helps us avoid stupid decisions. Unfortunately, it also prevents innovative, passionate, fantastic decisions. Collective Intelligence is collective insipidness. We need to keep the inputs of individuals in the mix.

There are 15 ways for someone to shutdown a laptop running Windows Vista. This adds unwarranted complexity to our software. How can we avoid the same problem in our software?