The art of communication.
Updated: Mar 9, 2019
For those of you that have worked as a business analyst , you may have been required to liaise with developers and clients as part of your role, and are probably familiar with the many layers of confusion you're presented with in your daily conversations. Common misunderstandings such as how the product should look, what the button should do, what events you need to call, what API's you need to build, how to handle a 503 or a 403... sorry, you lost me.
In all my professional years as a Business Analyst working within typical scrum teams, I've learnt that the art of communication has sat at the centre of delivering high-grade products. It is this very skillset that validates the need for business analysis in all projects, business or IT focused, where misunderstandings can be costly. I've heard many conversations between a client and a BA, or a developer, where there are clear misunderstandings (unknown to the participants), who only realise the discrepancy after development is complete. This has not only resulted in wasting time and money, it has also lowered the confidence levels from the client. Not to mention, creating frustration for the developer who has worked extensively through late nights and even weekends to meet the deadlines.
It used to strike me as odd though - that after many years of being taught how to communicate effectively, both verbally and written, that we are still lost on how to communicate simply. Surely, the art of communication is knowing how to communicate skilfully? I hope you're still following me.
During one of my projects, I overheard a conversation between a BA and a developer, who was attempting to explain a key requirement from the client. For the sake of this story, let's name the BA Henry and the developer, Sam.
Henry: "So, the Product Owner basically wants to be able to download a document. The user will need to enter key information, click confirm, and then download the document. Simple!", the BA smiled.
Sam: "What information is required?"
Henry: "The user's name and date of birth."
Sam: "What happens if the information is incorrect? Should they still be able to confirm?"
Henry: "Just add some validations to avoid that. I'll write the validations down on the user story."
Sam: "Do you have a process map, or some sort of diagram I can refer to?" Henry: "I didn't think we needed it for this requirement - it's very straightforward."
Sam: "What should happen if there's an error?"
Henry: "We inform the end user with a message."
Sam: "What format is the document?"
Sam: "OK, I think I understand. Thanks, I'll get started on it."
Henry walks away thinking that his work is done. He's successfully informed Sam of the new requirement, and the client will see a demo of the new functionality at the end of the sprint. Now of course, we'd expect there to be small workshops and scrum ceremonies, such as Refinement sessions, to aid the delivery of understanding requirements and the many possible scenarios that could occur. Fortunately, part parcel of Agile delivery is continuous feedback and improving functionality based on that feedback. But, we will touch on agile business analysis on another post.
A sprint later, and Henry was preparing the demo for the end client who was rather excited to see the new functionality. The demo is taking place in the open space and there is a TV at the front, Henry is connecting his laptop to the screen, the team and the client are sat waiting. Henry begins by setting the scene and then commenced to demo the new functionality. At the end of the demo, the team clapped and Henry patiently awaited feedback from the client. The client was sitting at the front with his arms folded.
Client: "Thank you for the demo, Henry. I have a few questions... Why is there no download link? I thought we were asking users to enter the FIRST and LAST name? And, why have we used the colours blue and green?"
Henry: "The requirement was to download the document when you click submit..."
Client: "I said I wanted to click "confirm" and then be taken to the download link."
Sam: "Henry, I'm sure we discussed that the document was to be downloaded when the user clicks on the "confirm" button? That's the trigger point."
Henry: "That's what I understood the requirement to be."
Client: "No, we spoke about this. The user enters his first name, his last name, and then his date of birth. They click "confirm" and then they are taken to a page where they can download the document." The client went on to ask about various error handling scenarios, which weren't largely defined nor demonstrable. Now two key things have gone wrong here:
1) The demo of the functionality did not satisfy the client (and, impacted the team spirit).
2) The requirements were not refined enough, and agreed between all parties.
The art of communication and communication skills are not the same. Have you ever heard of the phrase, "a skillfull artist"? A skill, or a skillset, is something that you can acquire over time through various means of learning. Be it through other people, formally or informally, or through observation. And with sufficient practise, you would have strengthened your ability to execute that skillset effectively.
However, despite our efforts to communicate well enough, it is the misfortune of perception that leads to infinite interpretations. And, this is where the art of communication becomes important.
An art, in my mind, is the ability to execute a skill creatively. Let's take an actual artist as an example - Vincent Van Gogh. Infamous for his "The Starry Night" painting, or his much loved "Sunflowers", he was skilled in rhythmic line structures and impasto (brush technique), yet it was his artistic side that enabled him to execute those skills creatively. Thus, creating a much deeper meaning to his artwork. (And, for the art critics amongst my readers, you may also argue that this led to various interpretations of his work. Ironic, huh?)
The point I am trying to make is that we need to get creative about how we communicate. And, we should not limit that to mere verbal means or writing user stories.
How we can improve our communication to ensure that clients get what they ask for, and to prevent costly mistakes from occurrin
Become an artist. No, seriously. Draw it all out! Process maps, UML, scribbles on a whiteboard - visual representation of user needs aid mutual understanding of requirements, and encourage the entire team to challenge the requirement. There are various UML diagrams that can be drawn up to define relationships between people and systems, or various entities. The most common ones that BA's may produce as part of their role are use case diagrams, class diagrams and sequence diagrams. The use case diagram is particularly useful to support discussions with developers and architects to provide a high-level view of key system functionalities. If you are not a technical BA, your technical architect is most likely responsible for producing class and sequence diagrams BPMN/Process maps are a useful resource in understanding the journey of a system or a process. You may find that BA's need to produce "as-is" and "to-be" process maps, these are used to define the key differences between the historical process and the future state. BPMNs or process Maps can be as detailed as you think necessary.
Write user stories following the INVEST principle. The INVEST principle is simple, it argues that a user story should be Independent, Negotiable, Valuable, Estimable, Small and Testable. By writing user needs down on a small card/post-it, and sticking it on a wall visible to all, you are encouraging key stakeholders to have a discussion each time they pass it. Discussions help transform the unknown into the known. Grab a small card and write the user need on the front of it in the format of: As a <user>, I want <need>, So that <reason>. This simple statement enables the team to understand a few key things: who are we building this for (the user), what does the user want to do (the functionality), and why do they want to do it (the purpose). Let's take this user story as an example: As a student, I want to be able to purchase books online, So that they can be delivered to my dormitory. Questions to consider for this user story: - What is the priority of this story? Use the MoSCoW model - Is this story truly independent? Does the website/application have an e-commerce store in place already with a payment gateway integrated? - Can we negotiate the scope of this story (i.e. which payment methods are considered MVP)? - Can we estimate how many points it would take to deliver (subject to further refinement) - How is this story valuable to the customer? Higher sales of books? - Is this story small enough to deliver? The second question will probably tell you - no, it's not small enough. In fact, this user story may even be an epic paving way for multiple user stories. - How do we test this - and are there any key things we need to understand to make it testable? (ps. we will touch on the INVEST principle in detail on another post.)
Hold refinement sessions where necessary. I hear this all the time - "No, we can't ask the developer to come to a meeting now, they're so busy and pressured to deliver." Whilst I agree that the pressures of delivery are continuously mounting, it's actually in the developers interest to attend meetings where absolutely necessary. You can hold an effective refinement session between the scrum team and the product owner for 30 minutes, reducing the likelihood of misunderstanding requirements and costing the project more money. It will also mean, you won't have to have further meetings thereafter to clarify those mistakes! To host a successful and meaningful refinement session, as a BA you will need to do the following: - Arrange a date and time suitable for all parties (product owner, scrum team, architects, and UX) - Arrange a location (meeting room or open space) - Make sure you have a working TV, and video conferencing capabilities with the ability to share screens for those who are working remotely - Load the user story and talk through the user need, the requirements and present designs. - During the discussion, clarify any questions and/or misunderstandings - Ask the product owner to actively make decisions (Can the Product Owner please provide steer on....?) - Summarise key discussion points to ensure aligned understanding - Update the story as you go through the session - Ask the development team and testers to estimate the story - Agree on next steps and assign action owners
Write clear acceptance criteria (AC). The acceptance criteria can be considered as the holy grail of a user story, as these are largely taken as the final requirements to be tested again by the developers. But wait - what is an AC, and how detailed do they need to be? An acceptance criteria is a testable scenario generally written in gherkin syntax. It ensures that the key stakeholders are in agreement of the requirement(s), developers and testers are aware of the key requirements that need to be tested against, and is used to demonstrate the user story to the client. Once the AC has been demonstrated to the client, the client will then happily sign off the story, therefore accepting that it has been delivered as expected. The level of detail, and the template in which AC's are written, generally vary from team to team depending on their own needs. Here's a summary of things to consider when writing an acceptance criteria: - Written in Gherkin Syntax using non-technical language As a <user>, Given <pre-conditions>, When <trigger>, Then <result - Consider the happy path and unhappy path scenarios. Will these be included under one user story or split out? - Upload designs where possible, and process flows - Write notes and link them to the statement in the scenario. These help clarify vague statements and allows for simple AC's that are easy to follow. For example When the user selects a payment method (Note 1) (Note 1) Payment methods includes VISA, Paypal, e.t.c. - Try not to go beyond 4 scenarios (even that's a stretch!) - Review with the product owner and tester, as they may think of additional scenarios
Talk to each other This may seem like an obvious one (and it should probably sit at number 1), but I often find that gaps and misunderstandings are a direct result of a lack of communication. Here are some helpful tips to get you chatting away: - Identify who is accountable/responsible and who needs to be informed/consulted? Product Owners, Scrum Masters, Architects (business/technical), Developers, Testers, Designers, Researchers, Third Parties - Do not make assumptions. I hear a lot of BA's making assumptions without seeking to clarify, which can lead to many issues down the line. There may be some assumptions that cannot be clarified, and must be raised and accepted between key stakeholders as an assumption. - Ask questions about everything. There really is no such thing as a stupid question. As BA's we are not expected to know everything, but we are expected to find the answer and be able to summarise this in plain english. - Relay what you've been told to confirm your understanding (helps with technical discussions) - Take notes so you don't forget the conversation, but remember it's okay to ask a few times. - Go back for further clarifications if the initial discussion wasn't sufficient.
So, my fellow BA's and readers, what has helped you have meaningful conversations? What techniques have you used? Detailed blogs on agile business analysis - tools and techniques, will be posted to help you become a BA Master. Share your thoughts in the comments below! Here's to many fruitful conversations!