This article is part of my work on Conversation Patterns for Software Professionals

Before we we'll talk about questions for setting priorities, we need to take a look at this issue from a stakeholder point of view. So, you are Stakeholder and I am Developer. Context is you want me to to deliver hot dogs to your team :) Here is our conversation:


You: Listen, we are waiting for hotdogs for four hours and we are starving. So, hurry up, pleeeease...

Me: Ok, ok! We are doing our best. When do you want them delivered?

You: When!? Four hours ago!

Me: I have a solution for you. Let's talk about your priorities. What is the most important for you: bun, sausage, or ketchup?

You: What? They are all equally important!

Me: It's impossible. Choosing priorities allows you to have your wants at least partially done. It is for your own good to prioritize your requirements. Besides, there is no two things in the world being equally important. So, again: bun, sausage, or ketchup?

You: But they ARE ALL important for us !^%@!#&!

Maybe the dialogue above sounds funny and you discovered a solution during a first reading. But it presents the structure of a typical conversation between a stakeholder and a developer.

The main issue is two points view. For most stakeholders their requirements are atomic. No matter how large they are: one LOC change or four-week long teamwork. For a stakeholder requirement is mostly atomic by design.

What Is The Need?

To set priorities the stakeholder need must be recognized first and this may be one of: an expected benefit or a problem to be solved.


To be clear, a human being is a really complicated object and the only things we have are models of its behaviour. All models are simplifications, but the may by useful or not. My model assumes that every requirement (functional, architectural or so on) of a stakeholder is driven by a need (an expected benefit or a problem to be solved or both). This model is extremely useful, so that I recommend it.

Questions for Discovering the Need (in the Priorities Context)

A stakeholder is mostly focused on the thing he wants, so it is good for your conversation to help him/her to name the need.

We'll use the Drilling Question Pattern. We'll ask a question with a presupposition there is a need back to the requirement. Because there are two types of a need (an expected benefit or a problem to be solved) you may ask two questions. One for presupposing an expected benefit and next one for presupposing a problem to be solved.

A structures for these questions are:
  • If you would to start [a benefit presupposed] now, what it would be?
  • If [a problem presupposed], which one you would give up first?

As you can see, assuming a benefit we asking for "achieving", but assuming a problem we asking for "avoiding". Some explanation of it you may find in article Don't Confuse a Need with a Feature.

You probably wondering: "Ok, but what kind of an expected benefit or a problem to be solved I should presuppose in my case"? Obviously it depends :) I'll give you a tip how to start.

There are two typical needs when you're asking for setting priorities in the business context:
  • One wants to use a system feature - that is an expected benefit
  • One is under pressure of time or money - that is a problem to be solved
So, now our questions for setting priorities might be:
  • I you would to start using a feature now, what would you choose in the first place?
  • Assuming you're lacking of money or time, which one of these features you would give up first?
I have mixed tenses intentionally, because benefits refers to the "future", but a pressure is being felt "now". So, if you are a native speaker, let me know how it sounds for you.

Let's Back to The Hot Dogs


You: Listen, we are waiting for hot dogs for four hours and we are starving. So, hurry up, pleeeease...

Me: We are doing our best. I want to ask you something. If it takes next two hours to deliver all hot dogs, would you mind to give up bun, sausage or ketchup?

You: !^%@!#&! We are taking buns, but NOW!

:) The dialogue above might happen, but it's trivial, huh? Let's take a look on the more realistic one:


1| You: Listen, we are waiting for hot dogs for four hours and we are starving. So, hurry up, pleeeease...

2| Me: We are doing our best. I want to ask you something. If it takes next two hours to deliver all hot dogs, would you mind to give up bun, sausage or ketchup?

3| You: Are you crazy! We want hot dogs!

4| Me: I see you are starving and I know we're late. I need more details to deliver hot dogs faster. May I ask you something?

5| You: Hit me.

6| Me: What it will happen when we don't deliver hot dogs on time?

7| You: I am afraid my boss will kill me.

8| Me: Listen, I'll give you two hot dogs off-hand for you boss. Would you mind to convince your team to wait? We will try to deliver hot dogs in two or three hours.

9| You: Hmmm...sounds interesting...

Again I tried to find a need (I assumed it is a problem to be solved = a hunger). This was line [2]. But my presupposition didn't meet your real need. So, I tried one more time in the line [6]. Your boss was your problem, not a hunger :). Starting from the 'boss problem' we build an acceptable solution.

That's all for now. Watch the blog for more Conversation Patterns.

Photo Credits: Bun, sausage, ketchup :)

.