Category Archives: Prioritization

Articles that discuss the prioritization of requirements. Prioritization can be used to weight goals, rule out features, or sequence delivery. Prioritization can be based on market comparison, value analysis, company strategy, or user feedback. Different strategies exist for making prioritization decisions, and we talk about them here.

Prioritization and Value Maximization

We all know the story about the emperor’s new clothes. I’ve been thinking about prioritization and scheduling, and as far as I know, no one is promoting that we maximize value – they (and we) have been promoting that we do the most valuable stuff first. Doing the most valuable things first does not result in getting value the fastest. In this article, we show why not.

Read the rest of the article …

Gadgets And Goals

What makes the best gadgets great? An understanding of goals and attention to design details. When we take a step back from writing requirements about software, and think about gadgets and goals – the perspective can help us write better requirements and make better prioritization decisions.

Read the rest of the article …

Nexus – Third Alpha Release Prioritization

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.

Read the rest of the article …

Nexus – Next Round of Prioritization

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.

Read the rest of the article …

APR: Process Deviation?

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.

Read the rest of the article …

APR: Scope and Vision – Vote On It

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. Read the rest of the article …

How To Start The Use Case Process For Agile Software Development

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 Incomplete Requirements

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 and Utility

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?

Differentiate Your Product – Circumvent Comparisons

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.