I spent much of the last year doing contract work as a Business Analyst in a digital delivery team. I wanted to note down some of the ways in which I’ve approached this role.
It’s not a role I’ve formally held before, but I’ve been able to apply my experience of working in roles like Technical Lead, Delivery Manager and Product Manager.
Favour storytelling over story writing
To deliver the right product it’s important that we build shared understanding about our users, their needs, and how we’ll go about meeting those needs.
User stories help us with this. Everyone likes a good story.
Going back to the original idea of user stories; we need to tell stories, and have conversations, to build that shared understanding. Not just write them down.
To quote Jeff Patton:
“Stories aren’t a written form of requirements; telling stories through collaboration with words and pictures is a mechanism that builds shared understanding.”
The initial user story card is a starting point. I try to write just enough to be able to tell a story, and begin those conversations.
Use fewer words
I try to apply what I’ve learnt from Content designers I’ve worked with. We put a lot of effort into creating clear content in the services we deliver. Why not do the same when communicating in our teams?
The general approach can be summarised by this classic Orwell quote:
“Never use a metaphor, simile, or other figure of speech which you are used to seeing in print. Never use a long word where a short one will do. If it is possible to cut a word out always cut it out. Never use the passive voice where you can use the active. Never use a foreign phrase a scientific word or a jargon word if you can think of an everyday English equivalent. Break any of these rules sooner than say anything outright barbarous.”
A picture speaks a thousand words
One way to use fewer words might be to draw a picture instead.
A picture on a screen or whiteboard is often clearer than a load of words.
Drawing pictures together as a group helps to explain ideas more clearly than showing a picture that was drawn earlier.
Some pictures are transient, and only needed for a specific conversation. Pictures that we want to refer to later are photographed and uploaded to Slack or Confluence.
Explain abbreviations
I work in an environment that is littered with obscure abbreviations. Explaining them when they’re first used in any documentation is helpful, particularly for people new to the domain.
Publish don’t send
I avoid sending documentation. Instead I publish it in one place, and share the link. Then everyone knows they’re looking at the latest version.
Tools like GitHub and Confluence mean the days of emailing documents around should be over.
If someone can’t access a particular link (network issues, anyone?), I export the content and send as a PDF, to make it clearer that this is a snapshot.
Elaborate little and often
It can take time to digest complex technical and domain concepts. Running lots of short sessions to explain things means that people have time to go away and think, and then come back and discuss them. It’s how we learn new things.
I usually bring one or two new features to a weekly elaboration session lasting under an hour. Sometimes we review the same feature in 2 or 3 sessions, as we learn more about what’s needed, and what our approach might be.
I consult with my teammates on the best time for scheduling these sessions, to avoid disrupting their Maker’s schedule.
Be the glue
I work in a multi-disciplinary team of Researchers, Designers, Developers, and Testers. Working as a Business Analyst means I can help bring these people together.
Faciliatating sessions like sketching workshops helps the team to come together to solve problems. It binds the team.
Take responsibility for product decisions
I built a trusting relationship with our Product Manager. This helped me to judge when to take decisions about the product myself, and when to consult others.
If I was doing this on a new team, I might try something like Delegation Poker, to agree who can make different levels of decision about the product.
By taking responsibility at the right level, I worked as a proxy product owner for an operational service we delivered.
What else?
These are some of the ways in which I’ve approached the Business Analyst role.
Are you a Business Analyst, or do you work with one?
How else do Business Analysts approach their work?
Joe Blogs 