As a business analyst in the world of Agile development, my working day starts like any other: with stand-up meetings. I check in with the developers I’m working with to see how they’re getting on and what they’re planning for the day ahead, and I check in with my fellow business analysts to make sure we’re all aligned on what’s next.
The core (and most obvious) part of my role is working with product owners to understand what they need, and the best approach to create it. But ‘business analyst’ is a broad role – and in Agile development, it’s even broader.
Back when I worked in organisations that used the Waterfall approach, I’d produce a requirements document, ‘throw it over the wall’ to the devs, and that would be that. But in an Agile setup, I’m much more involved in the whole process, from the moment a stakeholder makes a new request to the moment it goes live – and well beyond that point, too.
Whether it’s for Waterfall or Agile, a requirements document is where the development process begins. Sometimes, a client will come to us with a detailed brief; other times, it can be as little as a single sentence. It’s my job to work with them to break down even the most abstract ideas, then identify and record important information about their project, like:
The scope of requirements can vary wildly, from a whole new app – such as a support ticketing capability – down to adding a single input field to a search function, or adding an extra button to a contact page.
That means every set of requirements will include different levels of detail. They’re living documents too, so they’ll often change a lot during the development, release, and iteration cycle. However, that’s not an excuse for lax requirements – everyone still needs a clear goal to work towards, even if some of the particulars are likely to shift.
Another important thing to consider about requirements documents is that they’re not there to suggest solutions or approaches. As business analysts, we don’t want to lead developers down any specific path; requirements should give them everything they need to plot their own route to the final product.
When it’s done, I pass the requirements document on to our developers – and that’s where the other half of my job starts.
I like to think of business analysts as the glue that hold the development process together. During my week, there are a lot of different touchpoints with devs, other analysts, stakeholders, and product owners to make sure we’re all keeping pace and hitting the right milestones.
A decent grounding in the technical detail is vital for a good business analyst – you need to be able to understand exactly what the devs are telling you, and the best way to translate that back into business terms for your product owners, and vice versa.
But what’s most important – and often underrated – are the soft skills; the ability to mediate between the client and the devs, or frontend and backend dev teams, keeping everyone communicating and working towards the same goal.
One of the great things about Agile is that everyone is accountable for their section of a project. But this does sometimes mean that you’ll need to have a difficult conversation with someone if their work needs revisions. Without good interpersonal skills, these conversations can just end up being unproductive and demotivating, so I always try and be friendly, understanding, and proactive in my suggestions.
With the right team of developers behind them, organisations can build almost anything. But without an inquisitive, experienced business analyst in place, that process can be fraught with communication issues and unmet requirements.
As a business analyst, I give talented developers the structure they need to deliver the best possible products to our clients, and over the past five years, I’ve seen a lot of projects from the initial conversation, right through to delivery.
Got a project in mind? Let’s start digging into those requirements.
The benefits of Agile can be significant to a business, particularly in the current era and upcoming turbulent times we’re likely to be facing. Scrum master and Agile Lead, Tom Clark shares the benefits of ‘real Agile’ and how to avoid the buzzword version.
Unique to Headforwards, technical sprints offer valuable time for analysis, reflection, and upskilling. Product Manager Owen Hodge explains the wide-ranging benefits for all.
Product Owner Tom Goldring explains how we turn client needs into a living requirements document that our teams can use to guide software development.
Headforwards™ is a Registered Trade Mark of Headforwards Solutions Ltd.
Registered Address: FibreHub, Trevenson Lane, Pool, Redruth, Cornwall, TR15 3GF, UK
Registered in England and Wales: 07576641 | VAT Registration Number: GB111315770