maandag 4 april 2011

Prioritiy

"Everything has priority number 1"
"These features are all 'must haves', I have limited myself to the bare minimum"

Who does not recognize these reactions from his or her users?

Why do we put priorities? The general reason is inside the old rule about supply and demand: There is always more demand for features than time to realize them. This applies in all stages of an IT-system, and broader, in all stages of projects and products. In IT, it not only applies to features, but also to other requirements, to change requests, and to the solution of bugs.

The IREB foundation mentions several ways to determine the priority of requirements, and, surprisingly, not the most well know method of prioritization of all, the MoSCoW scale.

The first method is assigning a high/medium/low scale. Many development tools use such as system.

A second way, not mentioned by IREB, is the MoSCoW method. Basically, MoSCoW is an acronym of the the four levels of priority:
* Must - A Must have, without this feature the system/product has no valid reason tot exist.
* Should - should have this if at all possible in this timebox, the difference with "Must" is a matter of time. For example, not all reports are needed at the start of the operations.
* Could - These are often viewed as 'nice to have', and often a few minor things which cost few resources are taken up.
* Would - things which we would like to have if we had sufficient time - which we usually have not.

A third way is Carl Wiegers prioritization matrix. Basically he lists all features, and assigns each of them 4 values, ranked on a scale of 1-10:
- relative benefit
- relative penalty for not having
- relative cost
- relative risk
These four numbers are processed for each feature, and the result gives an indication of a features value.

The Kano model mentioned in a previous post roughly classifies features in three groups:
* Base factors: the factors without which a product will not be bought. For example, a laptop without screen, or a car without wheels. A customer wont mention them, he will take them for granted.
* Performance factors: those factors for which more is better. For example the number of colors in which a customer can buy a car, or the number of years of guaranteed problem free service of a coffee machine.
* Excitement factors: Those attributes which make a customer say: "wow!". These factors tend to degenerate into performance factors over time. For example an autopilot in a car would be a wow factor now, but may be common place in 10 years. An IT-system which gives AI powered hints might be a wow now, but the users will get used to it in a few years - if it takes them that long to get used to it.

Another way is to use a matrix with two different dimensions on the two axis. Two dimensions which spring to mind are impact or profitability, and effort.



In the example matrix to the left features A-F have been plotted in effort vs impact. A and E ave moderate high impact and moderate high effort. Features D and F, in the upper left quadrant, have low effort but high impact. It will be clear that these features should be considered as high priority.

Another good combination of dimensions to pair of, are impact and urgency. This one already has a name, it is called the Eisenhower matrix. For example, an incident with great impact may still have low urgency. It is essential to have clear, unambiguous definitions of both. For incidents in the operation of an IT-system, impact may be defined in terms of the number of users being affected. Urgency is easier to explain in medical terms: bleeding, suffocating and starvation may all cause death, but suffocation is the most urgent, followed by bleeding, with starvation coming last.
Let's have a look at some examples for IT systems and features. Let's define impact as related to the number of users affected, and let's define urgency as:
- essential to primary process, no workaround
- essential to primary process, workaround available
- not essential to primary process
Feature A specifies that every user will be able to print reports with the first sheet on special company paper. Obviously it scores high on impact, but urgency will be low - the first sheet on special paper is not something that is essential to a companies primary process.
Feature B specifies that the customers can purchase items through the website, and that this is the only sales channel. It will be clear that this scores high on both impact and urgency.


Sources:
* http://en.wikipedia.org/wiki/MoSCoW_Method - MoSCoW method
* http://www.processimpact.com/articles/prioritizing.html - Carl Wiegers priority matrix.
* http://it-maintenance.blogspot.com/2010/11/kano-model-explained.html - Kano model
* http://ireb.de/ - ireb.
* http://beanoriginal.net/deadlines-and-the-urgency-side-of-the-eisenhower-matrix/ - eisenhower matrix

vrijdag 1 april 2011

7 requirements myths

James Robertsen gave a presentation on March 31, 2011 for the Dutch chapter of IIBA, the International Institute of Business Analysis. James is always good for a nice presentation, and this presentation was no exception. His subject was: “Requirements myths”.

Myth 1: Requirements are about requirements.
Truth: Requirements are about a business problem. Don’t look where the light shines (which is usually a software problem), look beyond the software for the business problem behind the software.

Myth 2: Listen to your customers.
Truth: Your customers don’t come up with innovations. Ford: “If I had asked what people wanted, they would probably have said: ’faster horses’”. The same applies to Steve Jobs: he never held a customer survey in which people came told him they wanted an iphone.

Myth 3: Testers test software.
Truth: Testers should do end to end testing. They should also test the project plan, the vision document, the requirements, and so on.

Myth 4: Always write a complete set of requirements.
Truth: The 80/20 rule also applies to requirements.

Myth 5: Allow time for debugging.
Truth: Debugging is at the end. Instead, spend more time to get your requirements right.

Myth 6: Start with use Cases.
Truth: Start with understanding the problem.

Myth 7: With agile you don’t need requirements
Truth: You need requirements engineers for your vision document, your initial requirements set, your conversations, and your testing.

On a personal note, I am not enthusiastic about all of them. Some of them can hardly be characterized as a myth. For example, take number 5, allow time for debugging. No doubt I have been on the wrong projects for the last 20 years, but I have never seen projects where software was perfect and faultless when delivered by the programmers.

Something similar applies to myth number 3: Testers test software. Imho testers do test software. It is good to have a fellow worker review your products, and this has become standard practice in most big organizations. Lost of defects can thus be prevented. But he does have point when he says that testers can also have a look at the early documents. Personally I prefer to send early documents also to testers - if they are already known.

Other things are what we in the Netherlands call "Open doors", things which are obvious. Myth number 7 is such an example.

But I think he does have a point with some of the others, such as the complete set of requirements (myth 4) and stressing the business problem (myths 1 and 6).