×

Tag: Business analysis

What is the role of Business Analysts within agile?

Analysisng the role of the Business Analyst.

When we were looking at the Digital, Data and Technology (DDaT) roles and capabilities back in 2016, one of the roles we really struggled with was the role of the Business Analyst (BA).

Not because we didn’t agree that it was a role (because we absolutely did) but because we struggled to define the scope of the role in comparison to things like; Product Management, Design or User Research roles.

It’s one of the questions, that three years later still comes around regularly. Who is responsible for defining the requirements? What is the role of the BA?

Who holds the requirments?

The role of the BA in an agile team

One of the problems we had back when we were defining the BA role as part of the DDaT professions, was that the Government Digital Service didn’t have BA’s in their teams. Similarly, the original Scrum Manifesto only has 3 roles in an agile team, the product owner, development team members and scrum master.

Because traditionally, the BA acted as the link between the business units and IT, helping to discover the requirements and the solution to address them; when multidisciplinary teams bought those members together the role of the BA became less clear.

This has meant when adopting agile, different government departments implemented the role in slightly different ways. The biggest trap I have seen teams fall into was the BA getting stuck with all the admin roles for the project.

Roman Pilcher argued for those BA’s moving into Scrum there were two options, becoming the Product Owner, or becoming a ‘team member’.

While I agree that Business Analysts are a key member of a multidisciplinary team, I disagree with this assumption that everyone on an agile team who isn’t the scrum master or the PO is simply ‘a team member’ I think the Business Analyst is a critical role (especially for Product Managers!) that brings unique skills to the team.

So, first things first let’s look at what requirements are in the agile space.

Certainly, within digital government at least, we use a user centric design approach. We are developing products and services that fix the problems that our users are facing. We are identifying user needs and testing and iterating those throughout the product development lifecycle. A lot of the time this conversation about ‘user needs’ has replaced the more traditional conversations about ‘requirements’. Which is good in some ways, but has also led to a bit of confusion about what Business Analysts do if it’s not gathering requirements. Who owns the requirements now?

Are user researchers responsible for gathering the requirements from external users (user needs), whereas Business Analysts are responsible for gathering requirements based on what the business needs (sometimes called business user needs)?

That line of conversation worries me, because it suggests that we don’t need to carry out user research on internal staff, it forgets that internal staff are users too.

So, what is the role of the BA?

In my experience the conversation about who is responsible for gathering requirements is symptamatic of the limitations of the English language, and our obsession with ‘ownership’.

User researchers primarily focus on gathering more qualitative data; why users behave the way they do, how things are making them feel; probing their views and opinions to understand what it is they actually need etc. They will help understand who they users are and verify what the users need. They will work with the team to test design assumptions and help ensure the options being developed meet user needs.

Business Analysis primarily focus on gathering the more quantitative data about the process; both the ‘as is’ process, and the future process we are designing. They work to understand how many users are being or will be affected? What are the cost/time impacts of the problem as identified? What value could be gained through the implementation of any of the options the team are considering?

They help identify the stakeholders that will need to be engaged, and how to best engage with them. They will turn the user needs into user stories that the team can develop and identify the metrics and success criteria for the team to help them measure value.

Where you have a Product or Service that is live and being used by real users, the BA will work with Performance Analysts to understand the feedback data coming from the users.

User Researchers and Business Analysts will often work closely together, while BA’s will use tools like process mapping to identify pain points, user researchers will work with them to map the emotions users are experiencing so that we can fully understand the impact of our current processes and the value we can release by fixing the problem. When User Researchers are planning in research sessions etc., they will often work with BA’s to get the data on where best to test in terms of locations or user groups.

Good Product Managers will use both the Quantitative and Qualitative data to help them pick which options to test. Designers will help both the user researchers and business analysts look at the data and design prototypes etc. to test with users.

For me, each role is clear in its scope, and their need to work together to identify the right problems users are facing and the best way to test those; and it’s not about what individual owns the requirements, because the answer is the team do.

Theme vs. Epic vs. Feature vs. Component vs. Story

Probably the question I get most (after what is Product Management, and what is the difference between a Product Manager/ Product Owner/ Delivery Manger)… ok so the third most common question I get asked is “what I mean by Epic/ Theme/ Feature, Componant or Story, what is the difference?”

And given I get asked it so regularly I thought it was worth sticking my thoughts down in a blog, so that I can call upon it in the future for reference, but also so I can understand whether I’m using them differently to others.

Theme:

When I tall about a theme, I mean something like Accessibility. It weaves through pretty much all stories as a thing we need to consider, will be key in multiple epics, but is not a deliverable ‘chunk’ of stuff on its own.

Epic:

When I’m talking about Epics I’m talking about things like Payments. These are tied generally to a specific outcome or high level user need or part of the journey or process someone takes in using the service. “As a business I want to be able to pay my staff so that they are remunerated for their work” for example. All the stories within an epic are related to delivering that outcome, the stories collected in an epic deliver value together, but the Epic is too big to do in one sprint. An Epic may be made up of several Features, or it may not. If it contains several Features you may prioritise all the “must have” stories from the epic to deliver together, and come back to the “should’s and could’s” later. Or you may save up the stories to deliver all the stories together in one larger release.

Features and Components:

Sticking with the Payments analogy, given the scope of that Epic is large, it would probably contain several features and componants. a Feature would be something like your payments engine, a collection of stories you have to develop and deliver together to release value, whereas a Componant is generally something you can plug in like Bank Wizard. Neither of these things deliver the full outcome required, which is why they are not an Epic.

Just because you can physically pay someone doesn’t mean you can calculate the right payment for example, there will be other stories to allow you do that, all of those stories would sit within the Payments epic as you need them to meet the outcome you’re looking for, but would be developed separately to your payments engine or allowing you to plug in bank wizard.

Finally there are the stories and tasks that are fundamental to delivering everything:

Stories are the individual bits of ‘stuff’ you are trying to deliver. And the tasks are the actions you will undertake to deliver the story. So “as a manager I want to stop payments to members of staff who have left the business so that I’m not paying the wrong people” is a (terrible, sorry) story. It would still sit within the Payments epic, could possibly be part of a feature, but it meets an individual user need. The story would need to meet accessibility criteria, and there are several tasks you’d have to do to deliver it, develop a prototype or speak to stakeholders etc.

Originally posted on Medium