Katherine Moore

Business Analyst

Katherine is a business analyst with Headforwards, working with a global communications client. Prior to Headforwards, Katherine worked with Dutch information services company, Wolters Kluwer on multiple customer-facing projects. Outside of work, Katherine enjoys being outside in beautiful Cornwall, walking, paddleboarding, horse riding or in a beer garden!


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.

It all starts with a document

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:

  • Who the stakeholders are – and who has final signoff
  • Functional requirements (what the new software needs to do)
  • Non-functional requirements (how the new software needs to achieve its function)
  • The scope of the project – and what’s beyond the scope
  • Risk analysis, and a list of other systems this project will impact
  • What types of testing we’ll need, such as security checks or cross-browser compatibility tests
  • The release schedule and change plan
  • Potential wireframes

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.

Iterative development means a lot of back and forth

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.

Business analysts are there to facilitate

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.

Want to know more about how we use mobbing to deliver quality software? Get in touch