Business Analyst

Interview Questions
and Answers
A comprehensive guide to help you succeed
at Business Analyst interviews.

A Publication of
Preface

Almost every business analyst must undergo the interview process to

attain career growth. The interviewer's motive is to ascertain a
candidate's suitability for the said position. The better a candidate
prepares himself for the magnitude of questions that could be asked,
the greater his chances of getting selected.

To help you have the upper hand in the Business Analyst Interview,
we have come up with a multitude of questions that could be asked
throughout the process. The questions are divided into two chapters,
one for technical questions and the other one for agile.

Wishing you nothing short of absolute success for your upcoming

Business Analyst interview!

Keep Learning, Keep Growing.

Robin G.
Founder.
https://thebusinessanalystjobdescription.com/

2|Page
Contents
Technical Question and Answers . . . . . . . 4
Agile Question and Answers . . . . . . . . . . . 22

3|Page
01
CHAPTER ONE

Business Analyst
Interview:
Technical Question
and Answers

4|Page
1. How do you define a requirement?

A requirement is a component of a comprehensive solution aimed at solving a

problem or achieving an objective.

2. How do you define the role of a business analyst in an organization?

A Business Analyst is a liaison between different stakeholders in an organization.

They acts as a bridge and a connector and helps the complete project team work
as a tightly integrated unit.

Since stakeholders belong to different domains (e.g., finance, business,

marketing), it's imperative for a business analyst to be able to sort and balance
the needs of these stakeholders while fulfilling the business objectives at the
same time.

3. What is your requirement elicitation strategy?

The elicitation strategy depends upon multiple factors:

 Type of the project (support, enhancements, etc.)
 Availability of stakeholders
 Nature of requirements

One can take advantage of direct collaboration with the client and have
facilitated workshops, interviews, and observe the end users. In conjunction, one
can also use techniques that provide more precise information, like prototype
and scenario building.

4. What are the best practices you follow while writing a use case?

The following are the best practices to write a clear and well-documented use
case:
1. Create the use case from the ‘user’s’ point of view and not the system’s
2. Capture both functional and non-functional requirements in a use case.
3. Include use case diagrams along with the use case.
4. Include the UI details/notes in the use case.

5|Page
5. What do you know about scope creep?

Scope creep, also known as requirement creep, is a term that denotes

uncontrolled changes/deviations to the project's scope without an increase in the
other resources (schedule, budget) of the project.

Scope creep is a risk to the project and is usually caused by poor project
management, improper documentation of the project's requirements, and poor
communication between the project's stakeholders.

6. What are the skills that a business analyst must possess?

A business analyst must possess fundamental skills such as elicitation, problem-

solving, communication, and management skills. Alongside, they must have
knowledge of IT skills, Software development understanding, and domain
knowledge regarding the domain they are working for. For more details, read
here.

7. How do you avoid scope creep?

Scope creep is a hindrance to the project's success and could be avoided by:
 Clearly documenting the scope of the project.
 Following proper change management process.
 Informing the effects of the change to the affected parties before making a
change.
 Entering the new requirements in the project log.
 Refraining from adding additional features to the existing functionalities
(also called Gold Plating)

8. How do you deal with difficult stakeholders?

Stakeholders sometimes could be challenging to deal with, but we could

overcome this situation by:
 Patiently listening to them and being polite.
 Make them acknowledge the problem from a perspective they understand.
 Show a commitment to working with them.

6|Page
  Make them realize how their interests will be realized when they are more
open and collaborative.
 Engage them and make them know that their contribution is valued.

9. When are you done with the requirements?

We consider the requirements are 'complete' when:

1. They are elicited/extracted from all the critical stakeholders of the project.
2. They align with the project's business case.
3. They could be developed/completed with the resources available.
4. All stakeholders of the project agree with the elicited requirements.

All the requirements that pass the above four criteria are considered formal and
final. These requirements are then documented, signed off, and become a part of
the baselined project scope.

10. Can you tell us something about requirement Traceability?

Traceability implies that requirements are uniquely identifiable and can be
tracked. The single, most important document to trace requirements is the
Requirement Traceability Matrix (RTM).

Traceability must go backward and forward (i.e., from user tests and design
documents back through to high-level requirements and vice versa) for
maximum benefit.

There are a couple of benefits of having requirement traceability:

 In case of change requests, it allows an analyst to assess the impact of a

change (by identifying all the features and documents that will get
impacted by the change)
 Ensures complete coverage of requirements and avoids scope spillage as
well as scope creep
 It reinforces to the business community that their needs are understood
and illustrates how they will be met

7|Page
11.What is the importance of a flow chart?
Simply, a flow chart explains the flow of a process through symbols and text. It is
essential because it:
 Displays information graphically, which is more straightforward and easy
to grasp.
 Helps with process-related documentation.
 Assists programmers in writing the process's logic.
 Aids testing and troubleshooting.

12.What is UML modeling?

UML (Unified Modeling Language) is a general-purpose modeling language*

which provides a standard way to visualize the design of a system.

*A modeling language is any artificial language that can express information,

knowledge, or systems in a structure defined by a consistent set of rules. The rules are
used to interpret the meaning of components in the structure.

13.Why do we use an Activity diagram?

An activity diagram is a graphical depiction/flowchart of actions, representing a

stepwise listing of activities.
We use activity diagrams to elaborate on those processes that describe the
functionality of a business system.

14.What are some of the standard tools that a business Analyst uses?

Some of the common requirement management tools used by a business analyst

are:
 MS Visio
 Enterprise Architect
 Rational Requisite Pro
 MS PowerPoint
 MS Word
 MS Excel
 DOORS
 Balsamiq

8|Page
 You can learn more about these tools here.

15.What documents should a Business Analyst deliver?

Following are some of the primary documents that a Business Analyst creates
during the ‘planning’ and ‘execution’ phases of a project:

 Use case documents

 Process/business flow documents
 Requirement Traceability Matrix (RTM) document
 Functionality Matrix (FM)
 Functional Requirement Specification (FRS) document
 System Requirement Specification (SRS) document
 Activity/sequence diagrams
 Business Requirement Document (BRD)

16.How do you manage rapidly changing requirements?

Too many changes can be detrimental to the project's success; hence,

requirements should be managed carefully. One could do so by following a strict
Change control plan, according to which:

 We document when the change was requested, its description, and its
severity.
 We assess whether the change aligns with the project's business objective.
 We then analyze the effects of change on the project constraints.
 We communicate the tentative schedule, cost, and resource expenditure to
all the stakeholders.
 We implement the change only when all the stakeholders agree on the
revised project constraints.

17.What are the non-functional requirements?

Non-functional requirements or 'qualities' of a system are the requirements

used to judge a system's operation.
These requirements define how a system is supposed to 'be'. E.g.,
 Throughput

9|Page
  Usability
 Reliability
 Scalability
 Security

18.What do you think is better, the Waterfall Model or the Spiral Model?

Each project has different and unique needs, and thus the SDLC phases should
be chosen based on the project's specific needs. In brief:

The waterfall model follows a structured approach, with each phase having
specific deliverables. But, it has little flexibility, and adjusting the scope later is
quite challenging.
In the spiral model, estimates of project constraints become more realistic as the
work progresses, and it involves the developers early in the project. But, it takes
more time and a high cost to reach the final product.

19.What do you know about a misuse case?

A misuse case is the inverse of a use case and documents the scenarios that
should not happen within the system. Any person or entity can perform the
actions depicted in a misuse case in order to harm the system.

Misuse cases are usually used in the field of IT security and data protection.

20.What is the use of configuration management and version control?

The configuration management process consists of tools and policies you need
to manage a ‘consistency’ to your project’s attributes. These attributes could
include software, hardware, tests, documentation, release management, and
more. Having a configuration management process within a project ensures
governance of the project’s attributes while maintaining compliance and data
integrity.

Configuration management includes, but is not limited to, version control.

Version control assists in maintaining different versions of files and code so you
can track the changes made to the documents/software over time.

10 | P a g e
21.Describe your understanding regarding high-level and low-level
requirements.

When the project is initiated, the broad business requirements are defined as
high-level requirements and are captured in documents like business case,
project charter and Business Requirement Document (BRD).

As a project moves from its early stages and into the development phases, high-
level requirement documentation is used to develop more low-level functional
specifications and low-level business requirements like Functional Requirement
Specification (FRS), System Requirement Specification (SRS), use cases or user
stories. The level of detail increases as one moves from the Business Strategy to
the High-Level Business Requirements to the Functional Requirements and
finally to the Functional Specifications.

The intended audience of high-level requirements is the upper

management/business stakeholders, while analysts, developers and system
testers primarily use the low-level requirements.

22.Please explain the use of SDD.

SDD stands for the term System Design Document, a technical document
prepared by the technical lead or the technical architect of a project.
SDD consists of the project’s system requirements (functional and non-
functional), the technical architecture, and the database architecture to support
the requirements.

SDD acts as the mediator between business users and the system developers so
that the system developers may understand the business requirements of the
system they are developing.
SDD assists the development team in knowing where to put emphasis and end
up with a quality and objective-based system.

11 | P a g e
23. Do you follow any verification activities before you extend your
requirements documents for a review?

Certainly.
I have created a verification checklist which I go through before routing my
requirement documents for any internal/external reviews. Here are some of the
key components of my checklist:

 A thorough spelling and grammar check on the document

 Validate the font and formatting consistency throughout the document
 Validate whether the documented requirements are in scope (of the
project)
 Are all the business rules that must be enforced in this document
accounted for?
 Have all the business terms mentioned in the document been defined in
the project’s glossary?
 Are the requirements defined in the document testable?

24.What is Pareto Analysis?

Pareto analysis is a technique that is used to identify the issue that is causing the
most number of defects.

The problems and their respective defects are plotted in a bar graph, and the
issue which is causing the highest amount of defects is addressed first.
Pareto analysis is considered a creative way of looking at causes of problems as it
organizes data into logical segments for better research, comprehension, and
communication.

25.What can you tell us about BPMN?

BPMN stands for Business Process Model and Notation. It's a global standard
for graphically representing a business process in the form of a diagram.

BPMN contains graphic elements business users, and developers use to create
activity flows and processes. BPMN's four basic element categories are:
1. Flow objects: Events, activities, gateways
2. Connecting objects: Sequence flow, message flow, association

12 | P a g e
 3. Artifacts: Data object, group, annotation
4. Pool and lanes

26.Explain the difference between a task and an activity concerning BPMN

Activity is a generic term used to denote a process/sub-process and a

collection/group of a task, whereas a task is a self-contained piece of work.
Activities are continually refined and broken down into tasks while creating a
BPMN diagram.

A group or an organization performs activities, and tasks are performed by

individuals.

27. Are you aware of the term gap analysis and have you ever used the same?
Gap Analysis refers to comparing the present state of any product, process,
application, business, or organization to the future desired state and identifying
what needs to be done to bridge that gap between the present and future state.

Gap analysis concentrates on ‘what needs to be changed’ rather than ‘how’ and
results in giving quantifiable data against it.

Here are some of the tools/techniques I have employed to conduct gap analysis:

 SWOT Analysis
 Spreadsheets
 5 Hows / Questionnaire
 Fishbone Analysis
 McKinsey 7S

28.Are you aware of JAD?

Joint Application Development (JAD) consists of a structured workshop session

between the end user/client, project manager, business analyst, technical team,
and subject matter experts (SME) to facilitate the design and development of the
product.

13 | P a g e
Applications developed through the JAD development approach have higher
customer satisfaction and fewer errors as the end user are directly involved in
the development process.

29.Do you know about the term ‘force-field analysis’?

Force-field analysis aids in making decisions by identifying the factors for and
against a proposed change to the system.

The 'for' and 'against' factors are tabulated and are then analyzed, discussed, and
evaluated for their impact on the change.

30.What are Test cases?

A test case is a document listing all possible scenarios that could happen based
on an individual use case. Thus, every test case is developed with a use case as a
base.
A test case contains the main flow, positive scenarios, negative scenarios, and
scenarios covering non-functional requirements also.

The team’s tester writes Test Cases in a testing tool like Test Director, but they
can also be written in MS Word. A single use case could contain many test cases
that are clubbed to make a test scenario.

31.What are the different testing techniques you use?

Testing aims to verify and validate the quality of a developed functionality

according to the project requirements.
A Business Analyst does various types of testing, which are:
 Black box testing: This is functional testing where a BA validates that the
output generated by the system is as per the requirements/use case.
 Unit Testing: A BA does unit testing on a developer's machine to ensure
the requested functionality is achieved.
 Integration Testing: This testing is done when more than one functionality
is integrated to realize a more extensive, and complex functionality. A BA
does integration testing to ensure that the system performs as expected
after integrating different modules.

14 | P a g e
  Functional Testing: A BA is expected to conduct functional testing to
validate that the system achieves the functionality specified in the use
case/functional requirement specification document (FRS).
 Acceptance Testing: A BA and the client do the acceptance testing to
validate that the system performs as per the business requirements and the
product's acceptance criteria.
 Regression Testing: Regression testing is done after a modification has
been made to the existing system. It aims to ensure that all the system
functionalities are working as expected.
 Beta Testing: A BA and the testing team do the beta testing, and it is done
on a pre-production version of the product. This testing ensures that the
system's functional and non-functional requirements are met.

32.Tell me about SaaS

SaaS is short for Software as a Service.

It is a software delivery model under which an end user remotely accesses
software and its associated services as a web-based service. E.g., Salesforce is
deployed over the internet, and the users access its services by an internet-
enabled device.

33.What problems could a Business Analyst face during requirements

gathering?

Some of the problems faced by a Business Analyst during requirements

gathering are:
 Lack of clarity in the scope of the Business requirements.
 Misalignment of the requirements with the business case of the project.
 Ill management of Business Requirements.
 Constantly changing requirements.
 Unavailability of the key stakeholders.
 Communication gap between the stakeholders.

34.Could you describe the qualities of a well-analyzed requirement?

The golden rule to measure the quality of a good requirement is the 'SMART'
rule.

15 | P a g e
According to this rule, a requirement should be:
 Specific: The requirement should be unambiguous and consistent so that it
could be properly understood
 Measurable: Once developed, the completion of the requirement could be
measured/verified by specific criteria(s).
 Attainable: The requirement should be possible to attain with the given
resources (schedule, cost, and workforce)
 Relevant: The requirement should be in line with the project's business
case
 Traceable: The requirement can be traced throughout its life-cycle i.e.,
conception, specification, design, implementation, and testing.

35.What are the different diagrams that a Business Analyst should know
about?

There are several diagrams about which a business analyst should have
substantial knowledge:
 Entity relationship diagram
 Data flow diagram
 Use case diagram
 Class diagram
 Activity diagram
 Sequence diagram
 Collaboration diagram
 Component diagram
 Deployment diagram

36.What are the primary responsibilities of a Business Analyst?

A business analyst is expected to visualize the 'big picture, and his

responsibilities extend to both the business side and the technology side of the
project.

The major responsibilities that they are expected to fulfill are:

 Ascertain the feasibility of the solution/project/product.
 Analyze, organize and document requirements.
 Liaise and enhance communications with stakeholders.
 Clarify doubts and concerns regarding the solution to be developed.

16 | P a g e
  Conduct unit/functional/system/integration testing and verify the
development is as per the requirements.
 Gain acceptance/approval of the deliverables from the client.
 Document and prioritize change requests from the client.
 Create final product documentation, achieve records, and document
project lessons learned.

37.What are the different analysis techniques employed by a BA?

The principal business analysis techniques used by a BA are:

 Interviews
 SWOT analysis
 Facilitated workshop
 Brainstorming
 Observation
 Prototyping
 Root cause analysis

38.What is a 100-point method?

The 100-point method is a prioritization method that can be used to prioritize

items in a group environment. Each person within the group is given 100 points
which they can distribute as votes across the available items.

100-point method is usually used while defining the priority of implementation

of requirements.

39.What do you know about 8-omega?

8 Omega is a business change framework to improve the existing business

processes.

Based on its name, this framework consists of 8 life-cycle phases, namely;

 Discover
 Analyze
 Design
 Integrate

17 | P a g e
  Implement
 Manage
 Control
 Improve

Also, 8 Omega addresses four key perspectives of business i.e. Strategy, People,
Process, and Technology.

40.What is FMEA, and why it's used?

FMEA stands for 'Failure Mode and Effects Analysis' and is used for failure
analysis, risk analysis, and quality engineering.

It involves reviewing components, systems, and subsystems on functional,

design, and process parameters to identify failure models. The resulting data is
then used for risk management and mitigation.

41.What is a use case?

A use case is a methodology used in requirement analysis to identify, organize

and document the requirements.

Following are the main characteristics of a use case:

 Contains both functional and non-functional requirements
 Describes the flow of events/scenarios
 Defines the actors involved in the scenarios
 Contains main flow, alternative flows, and exceptional flows.
 Contains business rules and associated diagrams.

Use cases can be used at various stages of a project; its audiences are technology
and business.

42.Tell us the difference between an alternate flow and an exception flow of a

use case?

Alternate flows are the alternative actions that can be performed apart from the
basic flow and might be considered optional.

18 | P a g e
In contrast, Exception flow is the path traversed in case of an error or an
exception being thrown. For e.g., on an application’s Login page:
 The user entering their ‘username’, ‘password’ and then clicking the Login
button is the main flow.
 The user clicking the 'Forgot password' link is the alternate flow.
 The system showing a ‘404 error' in spite of the user entering the correct
username and password is an exception flow.

43.What is the use of triggers in a use case?

A trigger is an event that will invoke the initiation of a use case. The respective
use case will remain inactive if the triggers do not happen.

For e.g., a user opening the application’s login page is an event for triggering the
‘Login Use Case’.

44.What diagrams are used to visualize a use case?

Use Case Diagram is a behavioral UML diagram used to visualize the

requirement scenarios where ‘users’ interact with the system.
These diagrams clearly highlight the roles within the system, their activities &
characteristics, and the overall boundary/scope of the system being developed.

Here are the 4 objects used in a use case diagram:

 Actor: Any entity that is performing a role in or interacting with the use
case. Actors are named after a noun (person, organization, etc.) and
triggers the use cases. Actors are represented as a stick figure in a use case
diagram.
 Use Case: Use cases are represented as an oval in a use case diagram.
 Relationships: Associations that happen with the actors and the use cases.
Relationships are represented lines (solid and dotted) in a use case
diagram.
 Boundary: Boundary represents the scope of the current use case.
Anything within the boundary is the part of the use case and anything
outside is considered out of scope. Boundary is represented as a box in a
use case diagram.

19 | P a g e
45.Please explain the term Use Case Points

Use Case Points are a normalized unit of measurement used to size and estimate
the amount of work (effort) that is to be done on a system.

46.What is use case generalization and actor generalization?

In the context of use case modelling, sometimes, two or more use cases share a
common structure and behaviors. When this happens, we create a new use case
that describes the shared parts of its parent use cases.

Similarly, actor generalization is the relationship between two actors in a use

case where the child actor inherits the properties of a parent actor.

47.What are the advantages of unit testing?

Unit testing is the type of testing done at the developer's desk, and if a Business
Analyst conducts unit testing, they can find a defect before it gets integrated with
other features. Unit testing identifies a bug early in the cycle when the fix is easy
and the impact is low.

48.Elucidate the difference between assumptions and constraints

Assumptions are scenarios considered as facts while a product is being

designed/developed.
Constraints are restrictions that are imposed on the system and have to be
mandatorily followed.

49.Can you tell us something about SWOT analysis?

SWOT analysis, meaning Strengths, Weaknesses, Opportunities and Threats

analysis, is a widely used technique to perform structured identification and
analysis of the factors that will decide the outcome of any proposal, project,
product or business case.

The main aim of conducting SWOT analysis is meticulously listing down the
below attributes around your project/goal/situation:
 Strengths (qualities)

20 | P a g e
  Weaknesses (negatives)
 Opportunities (elements in your favor)
 Threats (risks)
Thereafter, each of the above factors is analyzed to see their impact on your
project or activity.

50.What is a RACI matrix?

RACI matrix is a type of responsibility assignment matrix used to assign roles

and responsibilities within the project team.
The acronyms stand for Responsible, Accountable, Consulted, and Informed.

21 | P a g e
02
CHAPTER TWO

Business Analyst
Interview:
Agile Question
and Answers

22 | P a g e
1. Can you elucidate something about agile?

Agile is a software development methodology in which the development is

carried out iteratively, and the requirements evolve through continuous
inspection and adaptation.
Some of the most commonly used agile software development
methods/frameworks are:
 Adaptive software development
 Extreme programming
 Scrum
 Kanban
 Lean

2. What can you tell us about Scrum?

Scrum is the most widely used process framework for agile development.
Concepts of Scrum include:
 Sprint: It's the basic unit of Scrum development and is restricted to a
specific duration (generally 2 or 3 weeks).
 Product backlog: A detailed listing of all the product's requirements.
 Daily scrum meeting: Each day during the sprint, the project team
assembles and discusses what was achieved yesterday, what is due today, and
the roadblocks faced. This meeting is strictly timed for 15 minutes.
 Sprint Review Meeting: A meeting that reviews what was achieved in the
course of the sprint and the quality of the features developed.
 Sprint Retrospective: Team members reflect on the recently concluded
sprint to learn from the mistakes made and document the ‘lessons learned’ to
continuously improve the sprint process and deliverables.

3. What is the purpose of the sprint planning meeting?

The spring planning meeting is held at the start of every sprint and comprises
the project team, product owner, and scrum master.
The aim of this meeting is to:
 Ascertain the capacity of the team for the current sprint.

23 | P a g e
 Prioritize the items from the product backlog to be completed in the
current sprint.
 Select the items from the product backlog to be done in the current sprint
based on the team's capacity.
 Plan the work and assign responsibilities for the complete sprint duration.

The entire duration of the spring planning meeting is anywhere between two to
eight hours.

4. What are the advantages of agile methodology over the other software
development methodologies?

Due to its innate nature, Agile development is both iterative and incremental.

Owing to this characteristic, all the development aspects (requirements, design,

and quality) are constantly reviewed and improved progressively with each
sprint.
Thus, the product could be adapted anytime based on the evolving business and
the stakeholder needs.
Whereas, in the conventional development methodologies, each project phase is
only traversed once, which restricts the flexibility to incorporate new
requirements or modify existing requirements.

5. How do you define a sprint backlog?

A sprint backlog is a collection of requirements the development team must

achieve in the next sprint.

A sprint backlog is created based on the development team's capacity and the
priority of the requirements. Conversely, a product backlog is a prioritized list of
high-level requirements of the product.

6. Why do we use a sprint burndown chart?

A sprint burndown chart is a graphic visualization of the current sprint's

progress rate (amount of work completed and the total work still remaining).

24 | P a g e
This chart is updated daily over the course of a sprint and acts as a guide for the
agile team to determine if their progress is as per the initially projected pace of
completion.

7. Who constitutes a Scrum Team?

A Scrum Team usually consists of anywhere between 5 to 10 individuals sharing

the roles of a:
 Product Owner
 Scrum Master
 Development Team

It is worth noting that all roles are considered equal within a scrum team and
there is no hierarchy or rank within the team.

8. Tell us the responsibilities of a Product Owner and Scrum Master

The duties and responsibilities of a Product Owner:

 Act as a primary stakeholder of the project/product
 Create, edit and prioritize user stories
 Add user stories to the product backlog

The duties and responsibilities of a Scrum Master:

 Act as a facilitator to the project team

 Makes resources available to the project team
 Enforces the scrum rules on the team
 Manage and encourage the project team
 Chairs and arranges stand-up meetings

9. What do you know about the term 'Spike' in relation to Scrum?

A spike is a time-bound activity to conduct analysis, due diligence or answer

questions rather than develop/produce a shippable product.

Spikes are usually planned to take place in between sprints.

25 | P a g e
10.What is the Velocity of a sprint?

The velocity of a sprint is the total amount of work the development team can do
over the sprint duration.

Velocity for a sprint is agreed upon based on the historical data available about
the previous sprints of the current project. In case the agile project is new,
velocity is calculated based on historical data for similar project types or industry
standards.

11.What is a 'Story Board'?

A storyboard represents the progress of an agile project.

To create a storyboard, a whiteboard is divided into four columns:

1. To do
2. In Progress
3. Test
4. Done
Post-It notes are placed in each column indicating the progress of the individual
development item (user story/task). This way, everybody is aware of the current
status of the project and the user stories as well.

12.Are you aware of the term 'Tracer Bullet'?

The tracer bullet is a ‘spike’ whose aim is to conduct some form of

technical/functional feasibility analysis on the project’s current technology and
architecture.

Tracer bullets allow the technical team members to assess the kind of impact the
introduction of a new feature/tool will have on the existing system. Accordingly,
future sprints could be planned basis of the results from the tracer bullets.

13.What do we mean by the terms ‘Impediment' with reference to Agile?

Impediment denotes the 'cause' that hinders the team member from working to
its fullest capability.

26 | P a g e
Some broad categories of impediments are:
 Limited technical knowledge
 Insufficient skills
 Unavailability of the required tool/software
 Lack of clarity with the requirements
 Cultural and organizational impediments
 People and personality issues
 Environmental impediments

14. What is the importance of user stories within an Agile project?

A User Story is a document that defines a system/project/product requirement in

the agile environment.

User Stories dictate a requirement's 'who', 'what', and 'why'.

To explain a requirement, a number of user stories might get created, each
defining a specific aspect of the requirement. These user stories are prioritized
based on their importance, broken down into tasks, followed by the developers
estimating the duration of completion of each of these tasks.

15.Have you heard of the term INVEST in relation to Scrum?

INVEST is a mnemonic describing the characteristics of an exemplary user story:

 Independent – The user story shouldn't have any dependency on any
other user story
 Negotiable – They could be changed and reframed
 Valuable – They should add value to the end product
 Estimable – It should be possible to estimate them for better planning
 Scalable – they should be small-sized and manageable
 Testable – The tester should be able to verify the end result of the user
story

16.How is an epic useful in an agile project?

While managing a large project, many requirements are spread across multiple

27 | P a g e
domains of the project, and it becomes difficult to manage such large
requirements.

Thus, these requirements are documented in the form of user stories, and the
user stories belonging to the same section of the project are clubbed to form an
'Epic'.
An epic is considered complete only when all the user stories (and their
respective tasks) belonging to it are complete.

17.What do you know about Planning Poker?

Planning Poker is an agile planning technique aimed at gaining consensus on

the estimated time to complete an activity. Team members are given Planning
Poker cards with values like 1,2,3,4, and these values represent the estimation
unit (hours, days).

Then, a user story is discussed, and the team members are called to disclose the
duration that an activity is expected to take by displaying a Planning Poker card.
If all estimators selected the same value, that becomes the estimate. If not, the
estimators discuss their estimates, and the same process is repeated until the
complete team reaches a consensus.

28 | P a g e
“ Thank You!

I believe the ‘Business Analyst Interview

preparation’ e-book was of some
assistance in your Interview preparation.

Good Luck with your interview.

Robin G.
https://thebusinessanalystjobdescription.com/

29 | P a g e