Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Conversation Patterns for Software Professionals. Part 1

Conversation Patterns for Software Professionals. Part 1

If you think that the business you are dealing with does not know what they want, you are in the right place.
In a series of articles you will learn methods of working with business people. You will learn how to manage a conversation, explore the needs and clarify expectations. Here we go!

Think, which of the following questions asked now – at the beginning of this article – will help you make the most out of its practical content:

  1. I am wondering what this article will be about?
  2. What was the most difficult part of my recent conversation with a client?
  3. Why do I make the same mistakes when talking to client?
  4. What new opportunities would arise if my conversations with clients looked the way I want them to look?

Which question do you pick? If you are not quite sure, I also encourage you to read this article. We will return to these questions a bit later.

Any software is created for someone – a person that will pay for it, a person that will use it. The main purpose of the software you have created is to improve someone else's work. Although, formally, all the people that will be affected by it are called stakeholders, software development teams frequently use the term – the business people, or even a shorter option – the business.

What is to be done?

If you want to write appropriate (that is, useful) software, you need to somehow get the information on what to do from the business. The difficulty lies in the fact that the information you get is very diverse. For example, you might hear:

  • Information about the current state – The report is not working.
  • An excerpt from a business rule – If a month has thirty-one days, I want to receive a notification at the beginning of next month, and if there are holidays, I do not want any notifications.
  • A story – I once saw similar software and it had such a nice feature that it could read amounts from sales receipts on its own.
  • An idea about ​​functionality – Let’s insert here some columns from the previous version, but in addition to ID let’s add two columns from the dictionary - in Polish and in Hungarian.

Although from the point of view of our clients these things are hitting the point, to create useful software we really need a lot more information. First of all, you need more details and concrete things.

Years of experience in the industry have shown us that the best way to get concrete and detailed knowledge from the business is to structure it. Structuring can be defined as organizing the acquired knowledge according to predetermined criteria, for example: functional requirements, non-functional requirements, domain-specific rules, architecture and implementation limitations. Such an ordered collection of information is a checklist for those who collect it and it helps them answer the following questions - What do I already know? What else do I need to know? What do I have to specify?

User Stories and Use Cases are not all

Two popular tools for structuring current information on tasks that the users will be able to perform in the system are called Use Cases (UC) and User Stories (US). For now, let’s skip the discussion about the differences between UC and US and when to use them1, and let’s move on to a few ‘did-you-know-thats’ about Use Cases and User Stories.

In the course of my work with various teams I have quite often come across some anti-patterns of forming US. Below, there are several examples:

  • AS an Operator I want to log in IN ORDER TO be logged in.
  • AS a Sales Rep I want to generate a monthly report IN ORDER TO see the monthly statement of sales.
  • AS an Advisor I want to make a new offer, BECAUSE the Product Owner wants it.

Again, for the sake of simplicity, let's skip the discussion of whether each of the US presented above has actually been uttered by the system user. The thing that is there in these examples, is the lack of an unambiguous formulation of the goals of User Stories. In a moment you will see that it has some really serious financial implications.

Similar anti-patterns apply to Use Cases. Experts point to the following weaknesses:

  • UC is too general,
  • UC is too strongly associated with a particular technology,
  • There are no alternative scenarios,
  • UC is too complex.

Both UC and UC were designed as tools to support collaboration between the business and IT. Their main purpose sometimes disappears from the foreground. Below, there are a few observations that I have had about this topic:

US and UC are treated as an end in themselves. Typically, the final goal of any programming project is to create a product or a service realized by means of software. The ultimate goal2 is the controlling parameter of listing expectations – in any form. Nevertheless, it is dangerous when the creation of UC or US "detaches" from the software delivery process – and becomes the art for art's sake.

UC and US are used as a shield against being bothered. In some contexts, the volume of documentation is inversely proportional to the subjectively perceived quality of cooperation of the business and IT. I have witnessed situations in which extensive and detailed UC was created primarily to make developers stop whining.

Instead of collaboration, let’s focus on completing the forms. We tend to unreasonably assume that writing down excellent UCs and USs is a guarantee of the project success. We often experience cognitive error called the social proof3. It's amazing that while appreciating the first value of The Agile Manifesto - Individuals and interactions over processes and tools, we are also able to give priority to tools. Maybe it's because this time the tools are “agile”.

The final business goal of the initiative is not clear enough. As an outcome of this we have stories or cases which are not aligned to the business goal. In that situation wanted features becomes just bunch of partially never used software functionalities.

Even with UC or US written down it is possible to misunderstand the business needs. There's a joke like that: once, in a small town three bridges were built, because ... only the third time the builders came across a river. You can do a lot of good and costly job without understanding what the project is really about.

User Stories, Use Cases and other methods used to shape then wanted software features or domain-specific knowledge are used in order to have a better understanding of what the business expects. There are also methods that allow you to model the business reality in a better way. Here, the following question arises – Where is the place for the business knowledge, the domain-specific knowledge, the expectations? The answer is obvious: in the minds of the business people!

If you specifically and concretely know what to do, saving it in any form: User Stories, Use Cases, scenarios, models or in any other way will be very easy. As easy as ABC – and you will even be able to write a script to do it J The difficult part of it is to extract business knowledge from people, to refine expectations and to separate things that are necessary from those that are only attractive. This is what Conversation Patterns deal with.

Conversation Patterns are methods of managing conversation, asking questions, searching for the needs and clarifying expectations. This is nothing but effective techniques that are used by people who are successful in gaining knowledge from the business. These techniques are named, organized and described in an algorithmic way to enable any IT expert to use them right away.

What is a need?

First, let us examine something that is prior to all Conversation Patterns. It is the need. What is a need? Read the following two statements:

  • I am responsible for the increase in the number of supported contracts to six hundred, SO I want to see a list of monthly contracts.
  • If the number of supported contracts will remain at the level of two hundred per month, they will shut our department, SO I want to see a list of monthly contracts.

These statements come from different clients who want the same functionality – to see the list of monthly contracts. The difference between these two statements is the reason why the functionality should be delivered. This reason is called a business need.

Since in these examples the expected functionalities are exactly the same, what is the difference in the business needs expressed there? If you take a closer look at them, you will notice that the first need relates to the achievement of a greater number of supported contracts, while the second one refers to preventing the department from being closed. These examples illustrate two groups of business needs – benefits to gain and problems to avoid.

Behind each functionality there is either an expected benefit or a problem that needs to be solved. If a business person does not see a chance of gaining benefits or avoiding problems thanks to implementing new functionality, it makes no sense to implement it. It makes no sense to pay for it!

If you understand what business needs are hidden behind the expected functionalities, you will understand what the business appreciates most. This is the business value of the functionality.

It is very easy to talk about functionalities, because they are tangible. You can draw the user's screen or the control flow. In the case of backend software, you can draw a diagram of components, or specify the API for the module. These things can be very easily named and defined. Finding and naming the needs is a lot more difficult, because they are usually hidden.

When you talk with the business people, in the first place they say what they want. They usually do not name their needs in simple terms. It is said that the responsibility of business is to determine what is to be done, while the responsibility of IT is to determine how to do this. I personally think that this borderline can be pushed even more. The task of the business is to determine why and for what the software is created, while IT may deal with what and how.

Before you start writing stories or use cases…

One of the greatest strengths, in my opinion, in software developments is that everything is possible. Every piece of functionality might be implemented with some effort. The strength is a weakness in the same time – team may deliver even useless features. If you ask for e-mail client – you will get it, if you ask for the bar code scanner – you will get it, if you want to choose a menu option with clapping your hands – no problem, team will deliver the feature. There is no limits in software development, everything is possible!

Business goal of the initiative is the critical thing which keeps all wanted features aligned to the one goal. This is the reason why main business goal (product, project) has to be clarified, understood and shared first by every involved individual.

Let is skip the part where we try to identify market expectations and assume that new product is desired by potential customers. The simplest but powerful tip for setting initiative’s business goal is quantification. In the example above we recognized two flavors of needs:

  • I am responsible for the increase in the number of supported contracts to six hundred…
  • If the number of supported contracts will remain at the level of two hundred per month…

These were already quantified in the dimension of contracts, but what about: time boundaries, contracts’ types, workers involved, reality check? All that question will help to quantify the business goal and will bring the better understanding of expected outcomes. Techniques for clarifying business expectations you will find in this and further articles of the series.

When does the business talk about problems?

Following the division of needs into avoiding problems and gaining benefits, let us assume that you are talking with a business person, for example, during a planning meeting. While you are trying to formulate a new User Story, your interlocutor says: As a user, I want the functionality X, because ...

  • ... I am afraid that the margin will be calculated incorrectly,
  • ... that GUI is unintuitive,
  • ... I don’t want the user to have the impression that (...).

If you listen carefully, in these statements you will hear some very specific phrase: I'm afraid that this is not, I do not want to. Similar examples include:

  • ... it works too slow, it does not work as it should,
  • ... it is too ...
  • ... the problem is that ...
  • ... this is impossible, because ...
  • is difficult, because ...

These phrases almost obviously indicate that the person you are talking to is trying to describe something he/she wants to avoid. Thus, he/she describes his/her need in the form of a problem to avoid.

Once the signals indicating the problem have been identified, the problem has to be named. It frequently fits into the following patterns:

  • I want to avoid ...
  • I do not want to ...
  • It is difficult, because ...
  • If we do not…, then ...

When you put the phrase that describes your problem in the place of dots, the sentence will make sense. For example:

  • I want to avoid incorrectly calculated margin.
  • I do not want unintuitive GUI.
  • I do not want the user to have the impression that.

When does the business talk about benefits?

During a conversation about new functionalities your interlocutor says As a user I want the functionality X, because ...:

  • ... we will be able to design reports on our own,
  • ... we'll use the salary calculator as soon as possible,
  • ... we will test this module in a better way.

Just as in the case of problems to solve, in the given statements you hear the characteristic phrase: we will be able, we will use it as soon as possible, we will test something better. Similar phrases include:

  • ... I expect that ...
  • ... thanks to it ...
  • ... it should /must /can could ...
  • ... it will be great, if ...

Here, you can name the benefit quite easily, because in most of the cases it fits it into one of the following patterns:

  • I want to achieve ...
  • It will make ...
  • This will mean that …

For the given example we have:

  • It will enable us to design the reports on our own.
  • This will mean that we will use the salary calculator as soon as possible.
  • I want to achieve better testing.

User Story vs. needs

Consider these two commonly used User Story patterns:

  • AS <role> I WANT <functionality>, IN ORDER TO <goal>?
  • IN ORDER TO <goal>, AS <role> I WANT <functionality>?

What, in your opinion, are the consequences of using each of them? Using the first pattern, you start a conversation from a functionality. Because talking about functionalities is quite easy and natural, you can spend a lot of time on: drawing screens, models or processes. Obviously, these are very important things, but at the end of the day you will want to have the whole User Story written down. Then, rather than the real goal, you will be tempted to use a vary general formulation – but it is only the real goal that motivates business to order a particular functionality.

The second pattern will bring a much better effect, because you start a conversation from searching the goal, that is, the business need. When you use the second template, you can start the conversation about the functionalities only on condition that you have first clearly defined the needs.

Note that you can use the knowledge about the needs to improve the template of the User Story. Instead of one pattern, you will have two that are more precise:

  • IN ORDER TO AVOID <problem to avoid>, AS <role> I WANT <functionality>.
  • IN ORDER TO ACHIEVE <benefit to gain>, AS <role> I WANT <functionality>.

Personally, I use double-sided printed cards. One side is for the pattern of gaining benefits, the other one for the pattern associated with business problems. With this template it is easier to notice the needs behind the requirements signaled by the business. Also, it will be easier for you to manage the conversation and, as a consequence, you will be able to offer a functionality that hits the nail on the head.

Which question have you chosen?

Let's go back to the first paragraph. Which of the proposed questions have you chosen?
I am wondering what this article will be about? This is question about "functionality". If you have chosen this one, you have read the article, you have learned its content and soon you will forget about it.

What was the most difficult part of my recent conversation with a client? This is a very valuable question, because it highlights the difficulty (the problem) that you are struggling with. If you have chosen this question, you will use this article as a source of potential solutions to this problem.

Why do I make the same mistakes when talking to clients? This is also a question about a problem, but if you keep asking this question to yourself, you will feel worse and worse. Of course, the ability to experience difficult emotions is useful, but in the case of this question there is no reference to the expected result.

What new opportunities would arise if my conversations with clients looked the way I want them to look? It is also a valuable questions, as it relates to potential benefits. If you have chosen this question, you will use this article as a source of inspirations to gain these benefits.

In conclusion: number two and four are the recommended questions.
In this article I presented foundation of discovering needs techniques. You know how to recognize need-like expressions during a conversation. But if you read carefully you would ask yourself: How will I know which of the needs expressed by the interlocutor is the real one? This is next step we will look closer: asking good questions for clarifying the needs.

If you want to learn more about talking with clients that do not know what they want, read the next part of the series.

About the Author

Michał Bartyzel – I have been dealing with the topic of the efficiency of the development teams for ten years so far. I am working on improving both the architecture of the applications and its refactoring, as well as on improving the cooperation between the so-called business and the development teams. So far, I have conducted more than five hundred training and consulting days with the best development teams in Poland. I have come to a conclusion that linguistic skills are the key to Software Craftsamanship. This applies to, both, the ​​cooperation with business and the developer’s job, which I show in the trainings that I design and dedicate to refactoring, working with code and architecture. Many techniques that I have developed so far are presented here. I also share some new techniques that I am currently working on during numerous conferences, on my blog and in the Programista magazine.


1 Those who are interested should first have a look at Alistar Cockburn’s book titled Writing Effective Use Cases and his blog.

2 There are situations when creating documentation is a vital element of the product business value. We skip them without any harm to the article.

3 Social proof in Influence: The Psychology of Persuasion, Robert Cialdini.

Rate this Article