How I prioritized the criteria to buy an apartment

“You need to choose because you cannot have everything for that price.”

This remembered me the typical discussions I had with our Product Owner when I was working in a Scrum team. “Prioritization” was the answer. The Product Owner was used to discuss with us the requirements, giving priorities to maximize the return on investment. This time I’m not working in a Scrum team, this time the context is different and it’s me playing the Product Owner role.

Here’s the situation: I’m looking to buy a new apartment. “You need to choose among your criteria because you cannot have everything for that price” is what the real-estate agent said.

Now I start to better understand my old Product Owner… how can I accept to buy an apartment that doesn’t match all my criteria? And which requirements can I eventually leave out? Like a “contrappasso” punishment it’s now me the one who needs to prioritize because most likely I will not find an apartment matching all my criteria. The main question is: which are the most important criteria I need to match?

Start with MoSCoW technique

I started creating an excel file to list all my criteria. I grouped them by theme (building, cost, plan, etc.) and I used the MoSCoW technique to have a first prioritization. I soon discovered I committed what I call the first Product Owner sin: everything is a MUST. It’s not easy to tell that something is not a MUST when you think you need everything… So the real question is: what is a real a MUST-have? Which requirements can I leave out? How much one requirement is more important than the other?

I started to turn the questions. Instead of asking myself “Do you need a parking?” I asked: “Will I buy the apartment without a parking?” “Will I buy the apartment without a balcony?” I realized it’s easier to give priorities considering how bad it is if a requirement is not matched.. I progressed with MOSCOW prioritization but I wasn’t fully satisfied yet.

I don’t need Financial Prioritization

In software development we can prioritize different features by business value: the financial value of the feature, the cost of developing that feature, the risk removed by developing it, the knowledge created, etc.

If I was looking for an apartments with the goal of investing my money I could use financial prioritization, but for me it’s important to find a good apartment where I want to live. I don’t want to consider the financial aspects now (ex: buy vs. rental, the internal rate of return, payback period, etc). I decided to do not use any financial prioritization. By the way I would be interested to know if some Product Owners out there really use it in software development, because I’ve never seen a PO doing it (unfortunately).

Use Kano Model on desirability

What I was missing is something to help me understand how the criteria influence my overall satisfaction when buying the apartment. Then I remembered the Kano Model that is based on the fact that customer satisfaction (my satisfaction in this case) is not influenced in the same way by all features. Some of them are in a linear correlation with satisfaction, others are able to provide great satisfaction but are not fundamentals and finally there are features that if missing would make me feel unsatisfied.

Following this model the features are grouped in three main categories:

Must-haves: all the mandatory criteria of my new apartment. Without these I will be not satisfied of my new apartment.
The more, the better: all the features for which my satisfaction is correlated linearly.
Exciting to have: all the criteria that can provide great satisfaction but for whose absence will not decrease my satisfaction below neutral.

The idea is to ask for each requirement a functional (positive) and dysfunctional (negative) question assigning a predefined type of answer. The functional question is to determine how do you feel if the requirement can be met. The dysfunctional question is to determine how do you feel if the requirement can’t be met. The answers together give a category for the importance of the requirement.

I added in my excel file a functional and dysfunctional question for each of my requirement and I gave an answer to these questions.

Example of questions and answers:

KanoCriteria Apartement

The functional and dysfunctional answers match a category following the map below:

Kano MappingA – Attractive
M– Must be
O – One dimensional
I – Indifferent
R – Reverse
Q – Questionable (reflecting unclear results which cannot be graded).

At the end of the exercise I visualized my criteria on a Kano chart. Here below a simplified version of it.


I found the exercise really useful to visualize what is important and to see how the apartment criteria are related to my satisfaction. I will give it to my real-estate agent hoping it will help to find my new apartment.

What do you think ? Did you buy an appartement ? How did you prioritize among your criteria ?


Planning the release

Today we created a rough product development roadmap. Normally there are two questions used to initiate the release planning:
– When do we want the release?
– What is the priority of each story?
For the first question not much choice, the date is fixed by the next release of the product at the beginning of September. Generally this bring to have a release planning with fewer variables to consider but with more difficult decisions about wich stories to include…  this seemed really the case. To decide the priority of the each story we used as a first step the MoSCoW rules (Must have, Should have, Could have, Won’t have this time). Claire assigned the rules, then the priority to each user story considering the desirability of the story.

From story points to expected duration
With each story estimated in story points what we needed was to convert these points into predicted duration for the project: the answer is to use velocity, the amount of work that the team can done in an iteration. To get the initial team velocity we took a guess (no historical value for the team, wait to run an initial iteration?). Our estimated velocity was at the end 12 so not possible to complete all the user stories for the fixed date, but this doesn’t mean will be our real velocity, after every iteration another more precise estimate will be done, changing the release plan.

Creating the Release Plan

The final step was to allocate stories into each iterations (6) following the priorities given. The result has been to have many user stories left outside of the plan, among them many user stories that marketing consider also as “must to have” for the customer… Claire didn’t seem very happy looking at the release plan. In any case tomorrow, planning the sprint iteration, we’ll take a look another time to our velocity and if we’ll see some important difference we’ll change it.

%d bloggers like this: