What else can you do apart from writing a great user story?

TLDR: Some personal tips I use to help get to a shared understanding

Have you ever had this super clear picture in your head of something? It could be a product feature you are working on, a work process or even where you want to go on holiday? Then you start explaining this to someone and you feel pretty sure you did a good job; you are an excellent communicator and they shared the same image you had in your head. For sure.

BUT for some reason when you get together again to talk about the same thing you realise… "hey… YOU DID NOT UNDERSTAND ME AT ALL!” (maybe not this passionately). What went wrong? Why didn’t they understand you?

Sometimes you may feel like this:

Thank you image from https://imgflip.com/i/102r93

Here are some simple things you can do to help you! (I have personally used all of them to varying levels of success. It really depends on who you are talking to)

1.Use your drawing skills

I mean YOU draw it. Do not call over a designer to come draw it out for you. Simply use whatever level of artistic skill you have and start drawing it out! Simple sketches will take you a long way! The purpose of the drawing is not to become a final design or the next Leonardo Da Vinci! It is simply to take whatever you have in your head out to the world so that they understand you.

Words: It’s this graphic in the middle of the page that’s shaped similarly to a star but with like, rounded corners.

VS

Just draw it!

Drawn by me and my fantastic drawing skills

2. Use post-its

Sometimes if you are talking about a flow: just use post-its! They are easy to move around and you can organise them however you like. They can be sequential, used for grouping, and for colour coding.

Expert tip: Stick them on wall so you can visit it again later if needed.

Thank you image from https://www.thoughtworks.com/insights/blog/7-tips-effective-inceptions

3. Use simple words

When you are using jargon or technical terms it is easy for YOU but not for the person you are trying to talk to! Try and think of how you would explain it to a 5 year old and go with that!

Example situation:

Super jargon:

Developer: Hey, I do not understand the business value of this card.

Me: Oh! it’s for illustrating the death benefit in the form of sum assured for the beneficiary!

Developer: What is sum assured? Who is the beneficiary? How do we illustrate it?

Me: Proceeds to explain everything in excruciating detail and end up in a rabbit hole

Simple words:

Developer: Hey, I do not understand the business value of this card.

Me: Oh! it’s to show the amount of money the customer would get when they die.

Developer: Ok, cool!

4. Use your acting skills

This is my personal favourite! When I try and explain something to a developer and they look at me blankly. This is my final card. You can assume the role of whatever you are trying to communicate! For example: you could act out the customer and play out your message. Or sometimes you can involve them in the role play as well! (However, I have yet to find a developer who wants to join me in my role play — insert sad face emoji here).

When I say role play- I do not mean you have to go away and write a script. I mean a spur of the moment role play! Use the empathy you have towards the customer

How to do it

• Set the scene (context)
• Explain who your character is
• Use the empathy you have for the person you are playing out
• Act your heart out!

Why do I do all this?

Everything I do, I do to get to a shared understanding! To me there is nothing more important that getting to a shared understanding with your team (or significant other). Without a shared understanding you are going to be working towards different goals without knowing until it’s too late.

It can SERIOUSLY help you save time. Sometimes, even after discussing in excruciating detail, using facts and figures, presentations AND calling in the big boss STILL does not result in a shared understanding. Just grab a piece of recycled paper and start drawing it or whip out some post-its and start writing! Pick a method that you feel comfortable using and try it out!

Thank you for reading!

Please do let me know if you try anything out and how it went : )

And hope I never have to do…

TLDR: A short opinion piece on what I feel are the perks of being an agile Business Analyst.

Warning: lots of random rants appear at irregular intervals

I have never gone through the actual horror of writing a Business Requirement Document (BRD)

It was my pleasure to watch my supervisor do it in one of the companies I had worked in . She is the most meticulous, detailed woman I have ever worked for. She produced a 200 page document that got thrown back and forth for 3 months. By the time it was finally deemed good enough by the IT department . We were already ready to start the "change request" process because we realised we forgot something or that something was no longer relevant or the boss had another changed their mind completely.

This is even before we saw the real product. And importantly, before any user had even heard, touched or tried the product (insert scream emoji here).

This got me thinking WHO on earth knows exactly what they want and can articulately document it in a 200+ pages ? Add in the condition that you are not allowed to edit this document after it is submitted. There will come a point where you are just adding in random crap because you are scared that if you forget it the developers will not make it for you. Then you get to be blamed for that missing functionality and so on….

Ok, I think you get the picture.

So let me tell you what I get to do instead !

I get to understand the customer first.
I get to work with talented User Experience (UX) folks who go out there in the field and discover what their pains are. We also get the chance to validate our assumptions and test prototypes (before a single line of code gets written!). This way we do not end up making something we think is fab and turns out the customer didn't really want at all.

I get to write stories continuously.
I have not been forced to write up all the stories ever needed with perfect acceptance criteria for a project before it can start. I write enough to start the iteration (and maybe a few more just incase velocity is off the charts). Instead of just throwing a huge pile of papers at them and having to repeat myself over and over again because they don't want to read my meticulously written document.

I get to tell stories.
I work WITH the developers, UX ,QA and PO's (occasionally the customer!). I tell them stories about the product, how it will be used, who will benefit from it. Sometimes I even do the occasional role play. I try to tell them in a way that makes them REALLY understand what it is they are making. Instead of just waiting for meetings once a week and have a boring mundane discussion where everyones starts checking for updates on their social media accounts.

I get to try out the working software ALL THE TIME .
I do not have to wait or nag a developer to try something. I get to see it when they complete it. I also get to cross check it with the story and passionately discuss with my colleagues the acceptance criteria. Instead of waiting months to try something.

In the end I just have to say nothing makes me happier and appreciative of being an agile BA more than the absence of the BRD : ) Work becomes less of a guessing game and more about collaboration.

Feedback and any questions are welcome!