When is v1 Feature Complete?
A member of the Software Craftsmanship group on Linkedin recently asked a question about how to determine requirements. Turns out he was asking about system requirements such as RAM and processing speed.
I interpreted the question as one about feature requirements because, well... that is the kind of requirements that I spend my time thinking about. In any case, how might a team determine minimum feature requirements?
There are more than a few ways to go about deciding what the minimum requirements actually are. Not only that, but depending on where you are in the product lifecycle and which member of the team you ask, there are various criteria for what the minimum should be. The product team may be pushing for innovative new features that will differentiate the product (and make it more attractive for purchase). The development team might be fighting to clean up some debt that they took on early in the project. The QA tech might have found some usability quirks that other members of the team do not want to prioritize. But in order to try to be helpful and answer the question, I will make a few assumptions.
I will assume that you are closing in on the first non-beta release - version one. I'll ignore Dev concerns for refactoring as well as any lingering QA issues. We will only talk about building features. In this case, your primary driving force should be to satisfy the users. My recommendation for determining the minimum requirements in this scenario (and the way we have begun to do it at Didit.com) is to use the Kano Model. Our process draws heavily from one of the books in the Robert C. Martin series - Mike Cohn's Agile Estimating and Planning.
Author(s): Mike Cohn
Publisher: Prentice Hall Professional Technical Reference
I am not going to try and explain the whole Kano model. I am a user, but not an expert and it is an entire course of study in and of itself. I will lay out the steps that you would want to follow and what Kano gets you. There are at least two prerequisites. The first we just discussed and that is having of a superset of the required features defined. The other is access to twenty or more likely users of your product who are willing to help by thoughtfully answering some multiple choice questions that you will pose. A third possible prerequisite is to read the Cohn book. Don't question this one, just do it. There is a lot more than Kano in there and all of it is good for you to know.
Now down to business. Write down all the features you are considering on 3x5 cards. Some features will be big and would involve many user stories. After you run these feature cards through the Kano machine, you can lather, rinse and repeat. That is, by breaking the "must have" features down into stories and Kano-tizing them, you may find that some stories can also wait. But I am getting a bit ahead of myself.
Take each card and make it into two questions - one is called the functional form of the question and the other is the dysfunctional form of the question. For instance if the feature is "As a Gliffy user, I want to be able to easily align the text in an object to the top/bottom or center of the object" then the two questions might read:
1a) If you can easily align the text in an object to the top/bottom or center of the object, how do you feel?
1b) If you can not easily align the text in an object to the top/bottom or center of the object, how do you feel?
Do this for every feature card that might go into the release.
The answers are a regular cut and paste extravaganza. There are five multiple choice answers for each question. Yup, every question has the same five answers and they should be repeated in the same order every time:
A) I like it that way.
B) I expect it to be that way.
C) I am neutral.
D) I can live with it that way.
E) I dislike it that way.
Get 20 or more questionnaires answered by your users. We have been using Google Docs Forms with good results. Next you arrange the five answers as the axes on a 5x5 matrix (repeating the five answers in both the x and y dimensions). Kano gives us a pattern of categories into which the answers can fall.
There are six categories:
1) Must Haves - M
2) Linear Features - L
3) Exciters - E
4) Indifferent - I
5) Reverse - R
6) Questionable - Q
The matrix looks like this.
Like Expect Neutral Live With Dislike Like Q E E E L Expect R I I I M Neutral R I I I M Live With R I I I M Dislike R R R R Q
The model defines three types of features, "must haves," "linear features" and "exciters". Must haves are, well... features that your product must have. Without must have features, users will not be happy. Incidentally, you can never implement must have features so well that users are ecstatic. They must be there, but overbuilding them does not make users happier. Linear features are good ways to build satisfaction. Users like these features and the more they have, the more they like it. Exciters are the features that are very cool and pretty unexpected (like wifi on a plane).
In addition there are another three categories of answers; "indifferent, " "reverse" and "questionable". An indifferent means that the user's just don't care. Building a feature about which the users are indifferent is a blatant waste of time. A reverse might mean that users prefer the absence of the feature. When you see a reverse, you should switch the functional and dysfunctional answers and see what the matrix says this time. Go with the answer as if the functional and dysfunctional forms had been reversed. A questionable answer probably means that a user did not understand the question. Or perhaps they are just not trying very hard. Imagine I ask, How would you feel if I hit you on the head? and I also ask, How would you feel if I did not hit you on the head? It seems questionable if you respond that you "like it that way" both ways.
Once you have a nice size group of answers, you may see clusters form that indicate a bimodal answer. This is generally a sign that there is segmentation in the survey group. Our questionnaires are anonymous, but we add a question up front where the user describes her role. This allows us to zero in on what each group of users is saying. Imagine the unlucky case where the primary users of a product are indifferent about a feature, but the managers that make purchasing decisions consider it an exciter. What would you do? You might want to convince yourself that those managers are visionaries because there will surely be some people at your company who want that feature built. From the standpoint of making the sale, they may even be right. But ultimately you probably should focus on the actual users and the way they perceive value.
So now you have answers that tell you what the "must have" "linear features" and "exciters" are. Perhaps you found some things about which users are indifferent. Awesome... drop 'em. You need the must haves. You do not need every must have to be exhaustively built out, but they all need to be in there. So here is the big question that I can't answer for you... Do you need to build linear features and exciters as a "minimum" for v1?
It depends on the nature of the product. Is it for sale? Is it competing against other solutions that are already established? The product team will have some ideas about this. It is entirely possible that you are done when all the must haves are done. But you will not have a very exciting product and you will at best make the users only marginally satisfied with your product. Can you get all the must haves, five or six nice linear features and a couple exciters built? That would be nice. But if you can only afford the must haves for v1, get the v1.1 release started as soon as that last story is committed.
User satisfaction is a moving target. You will need to ask about unbuilt features again. And again.
In February 2010 I was happy to find that someone had built a webapp to help administer and tabulate Kano Surveys... Check this out this very nice online Kano Survey tool http://www.kanosurvey.com/. KanoSurvey.com was written by Sergey Dmitriev of Making Waves, a European design and technology consulting company with offices in Oslo, Krakow, and London. Sergey also read Mike Cohn's Agile Estimating and Planning and was moved to create a tool that is free to use as a way of giving a little bit back to the community.
Thank you Sergey.