The one who communicates 24/7 and delivers sudden news (not always good), who is often associated with a product owner and whose decisions someone will always be dissatisfied with. Don’t let these clichés cast a pall over the Business Analyst’s (BA) role for software development. This article explains why every IT project can’t do without a business analysis and why a BA’s work is a worthwhile investment.
Let’s say you’re building a big house with a professional team and high-quality construction materials. Everyone’s ready to get to work, but there’s a problem: you can’t decide how many floors and rooms you want, how much everything will cost, or whether you need a house at all.
If we draw a parallel between building a house and product development, then the IT business analyst is the client’s and developer’s best friend. The BA’s goal is to unite the visions of both in one context at each stage of the workflow.
In software development, the business analyst helps clarify the customer’s requests (e.g., an idea for a future product), the product requirements — spoiler: they’re harder to define than it seems — and then transfers this information to the development team, so they can start finding and implementing a solution.
As you can see, the business analyst in an IT company is a real Swiss Army Man who builds a bridge between the developers and the client in the initial stages of a project. That’s how it works at Django Stars.
In some outsourcing companies, the BA sticks with the project at all stages, through thick and thin. This is not a practical approach, though sometimes it can be justified – for instance, when you need to report on each decision when developing health and safety-related products, government products, or tender-based projects.
This approach is slightly outdated and contrary to one of the 12 principles of the Agile Manifesto — ‘Not to do what complicates the development process or delays it’. We at Django Stars are always looking for well-crafted solutions and ways to achieve them.
Long story short, the BA finds out what the client wants, evaluates the product requirements, and, together with the team, chooses the solution that will best fulfill the client’s goals. Also, BA helps the team to provide cost estimates for the project. Upon delivering the product requirements to the development team, the BA together with the team does an estimation workshop that results in the effort estimates from the team with implementation notes. Finally, the BA works with a vast amount of data.
However, at different stages of the process, BA functions will vary.
According to the Agile Manifesto, we prioritize functional software over comprehensive documentation. In our team, the BA participates only at the initial project stages: the Pre-Sale, Discovery and Pre-Development. At the Pre-Sale stage, the Business Analyst clarifies the product idea and studies the documentation, if any. Then, the BA transmits this data to the team, which proposes a solution, and Pre-Development starts immediately, if the contract is signed.
If there is no documentation at the Discovery stage, the BA identifies and collects requirements from the product owner (and generates initial documentation).
So, the BA is fully responsible for aligning the team’s work to the stakeholders’ requirements and delivering the project context to the team.
At Django Stars, the IT business analyst’s role is limited by the initial stages of the project. Some may view the Discovery and Pre-Development stages as almost the same, but they’re actually not.
Software Consultancy Services
Unleash your product’s potential with our expertise.
The conceptual difference is that on the Pre-Development stage, the team already has an action plan and the initial documentation.
The Pre-Development stage assumes an emphasis on the preparation for development, which means:
- development environment setup
- preparing tools
- testing documentation preparation
- backlog creation to at least two sprints (with precise tasks and more detailed decomposition).
After all this, the team starts writing code and performing development tasks.
At the Discovery stage, the customer may not even have any product documentation. During the Discovery stage, the information about the future product is synthesized and analyzed, the work scope and project boundaries are determined.
Despite the specifics of the work scope and general duties, in the early development stages, the BA’s key responsibilities include:
*if the answers to the questions below are not clear, BA holds the Discovery phase
|Elicitation of the Opportunity as seen by the Client (What problem are we solving?)||Creating a project scope and defining milestones||Communicating the project context to the project team|
|Discussing other attempts (What has been tried before?)||Composing a High-level Solution Concept diagram that details how to solve the problem||Sharing previously prepared artifacts (estimates, client requirement documents, agreed-upon points)|
|Clarifying why the current state needs to be changed||Facilitating brainstorming sessions between all the stakeholders, knowledge matter experts and engineering team||The kickoff presentation for the team and client|
|Documenting the current state||Visual Collaboration and Diagramming, breakout sessions on specific subjects||Planning sessions and workshops|
|Defining the Win Conditions for the Opportunity (What do we need to achieve?)||Documentation of the results of the Discovery phase for further use||Facilitation of team exercises and workshops|
|Defining what has to work for us to be successful||–||Creating the project scope and defining milestones|
|Eliciting the actual needs of stakeholders||–||Provides team support to start the project smoothly|
The BA is responsible for ensuring that the team can quickly start development with a defined context and an initial solution plan so that later (when the BA finishes their participation), the team and the client can get along.
So, one of the key responsibilities of the software development business analyst is to elicit the actual needs of the stakeholders and state how to address them.
How to find out what the requirements are?
To be clear, it’s necessary to understand the logic behind the emergence of the requirements at each stage.
Some business analysts find it hard to understand the critical differences between requirements. This lack of clarity often leads to the creation of useless functionality and features and a product that will never work properly.
Business Requirements are the highest-priority requirements and are generated during the Enterprise Analysis. They shape the top OKR (Objectives and Key Results), and business problems to go down to the next level of detail.
Stakeholder requirements refer to stakeholder needs and pains (as well as users’ pains), and to their interaction with a future solution. User requirements are usually used as basic input data to create system requirements.
Solution requirements contain the system features that developers need to build a solution and are divided into functional or non-functional requirements and transitional ones.
Functional requirements describe what must be created on the product side to deliver a solution, while non-functional requirements cover everything else — whether it’s quality requirements, service-level requirements, or external interfaces.
Transition requirements describe the solutions needed to move from one step to another, and are no longer needed once the transition is complete.
Functional and non-functional specifications are often written in one document but can be produced as separate deliverables, as shown above.
Further, following the requirements, the BA conducts an Estimation Workshop with the entire team (including the designer and QA engineer), which helps the BA estimate the required resource costs to implement the proposed solution.
The Discovery stage ends when the final documents and the client presentation are ready. At the Pre-development stage, in addition to planning sessions and involving different team members and external stakeholders, the BA is also involved in the processes.
Planning and monitoring — which are one of the BABOK (Business Analysis Body of knowledge) key knowledge areas — are the basics, but the BA’s role also includes:
- Creating a detailed business analysis, outlining problems, opportunities and solutions for a business
- Budgeting and forecasting
- Variance analysis
- Defining business requirements and reporting them back to stakeholders
What types of documentation does BA develop during the process?
- A commercial offer
- Vision and Scope (the general vision of the system and its boundaries)
- Software Requirements Specifications / Solution Documentation (the full description of the behavior of the system being developed): BRD (Business Requirements Document), BAP (Business Analysis Plan), RMP (Requirements Management Plan)
- The acceptance matrix
- Software Design Document (optional)
- Presentations to both parties in the process
Well, you can, if you have a product owner on your side who has experience in working with the development team and knows how things are supposed to operate.
BUT if you’re not sure about the competence of the product owner, it’s better to delegate the task of transferring information to an experienced BA.
If there’s no BA on the development team, you may end up misunderstanding the process. And here’s why.
A user story (one of the tools for forming a solution) describes the context.
Let’s say the user story of entering personal data in different types of products will lead to different results — say, the users can order food at home or subscribe to tracking their movements.
The product owner and the team must understand the context in the same way. They must be in the same ballpark.
The BA is the communication link between the product owner and the software team. Thus, BA saves the client time and money, which might otherwise be spent on correcting misunderstandings.
In addition, the BA can objectively assess the effectiveness of the solutions offered by the client (if any).
The product owner doesn’t always make viable decisions; therefore, the IT business analyst’s role is to prevent bad decisions from prevailing and offer a more efficient solution — one that’s more elegant, reliable, or faster.
Having BA on even the most experienced Scrum teams brings many benefits.
- Common context for the team and product owner. By organizing the team, the BA helps to contextualize the requirements and provide detailed and timely documentation.
- Fewer defects, more components. If the team clearly understands what’s required, the likelihood of errors is reduced. This allows cross-functional teams to work on a feature simultaneously.
- Faster development. The BA produces relevant and current requirements to finalize user stories just in time.
- Only core features. All user stories created during the Discovery or Pre-Development stage are subject to validation against the original business goals. Inappropriate elements are cut out of the backlog, so the team doesn’t waste time developing features that won’t be used.
- Imagining the end result in detail at the project start. BA ensures that the solutions developed at the initial stages of the project will lead to the desired end result.
Having a competent BA is half the battle. But the success of business analysis largely depends not only on the BA but also on client. What does BA need to do his best work?
- First, requirements should not contradict each other. Otherwise, the formation of the solution will not be correct.
- Access to all stakeholders is needed to fully carry out the collection and discussion of the requirements from all sides.
- Time (which is limited).
- The willingness of the stakeholders (client) to answer all questions from the development team.
- Ideally, the client should have an initial documentation package (at least, the idea should be described in detail, not limited to a couple of theses).
- After the business analysis is complete, all artifacts are validated with the client, who should also be available for the report.
The business analyst in an IT company may have varied background, starting with UX design and tech writing and ranging to QA engineering and software development. According to the IIBA, the technical skillset may differ, but every business analyst should have the following basic skills.
You know what skills a business analyst for software development must have to start the project, what the task pool includes, and why a BA is most often indispensable on the team. Now you need to find the perfect one.
How to ensure you can trust professional qualities of your BA
Ask yourself, “How can a BA be of use to me?” If the BA can self-present competently and can answer this question, they are probably a good communicator, which is extremely important for setting up a bridge between the client and the developers.
Watch how the BA describes further work. There should be a clear structure containing the stages, and the relationships between them should be transparent. This indicates that the company’s processes are streamlined and you won’t waste time resolving misunderstandings.
Evaluate the company’s willingness to make contact — is it ready to provide you with direct communication with the developers? This means that the company performs the work with available resources only (no hidden freelance work force) and is fully responsible for their performance.
It’s a good sign if the BA offers more straightforward ways of solving your requests. This means the BA values your time (and money) and is experienced.
Without business analysis, the development process can look like a train journey to nowhere. And though the trip may seem like an adventure, then, in business development, it means the risks are too high.
In the days before business analysts, requirements could be prepared by the clients. But this didn’t always work: representatives of large companies lacked the resources, time, and knowledge to create documentation for the development team.
Due to poorly prepared documents, release dates were often delayed and left customers and performers dissatisfied. Business analysts finally made the process of collecting requirements faster and more systematic.