67 Most Asked Business Analyst Interview Questions and Answers [Free PDF]

If you are preparing for a Business Analyst interview, then examining the Business Analyst interview questions beforehand will give you a flavor of the type of questions you might be asked. It will help you understand what the interviewer would want to listen to and thus prepares you to be able to furnish answers that are relevant basis your experience and skills.

In this post, we have curated 67 frequently asked Business Analyst Interview Questions, along with professionally crafted answers under the below sections:

a) Section A: Fundamental Business Analyst Interview Questions
b) Section B: Functional Business Analyst Interview Questions
c) Section C: Technical Business Analyst Interview Questions
d) Section D: Agile Business Analyst Interview Questions

You can also Click the below link to instantly download the 65+ interview questions (along with detailed answers), bundled in a slick PDF document:

Download the FREE 65+ Business Analyst Interview Questions e-book and Resource Guide.

SECTION A: Fundamental Business Analyst Interview Questions

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 act as a bridge and a connector and help 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 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.

4. 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 primary 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.
• 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.

5. 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.
• 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.

6. 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.

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. Can you tell us something about the 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

INSTANT DOWNLOAD: Download the FREE 65+ Business Analyst Interview Questions e-book and Resource Guide.

9. 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

You can learn more about these tools here.

10. 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)

SECTION B: Functional Business Analyst Interview Questions

11. What different diagrams should a Business Analyst 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

12. 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

13. How do you define your requirement elicitation strategy?

 A business analyst’s requirement 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.

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

The following are the best practices for writing a clear and well-documented use case:

2. Create the use case from the ‘user’s’ point of view and not the system’s
3. Capture both functional and non-functional requirements in a use case.
4. Include use case diagrams along with the use case.
5. Include the UI details/notes in the use case.

15. 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.

16. 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.

17. 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.

18. 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
• Usability
• Reliability
• Scalability
• Security

INSTANT DOWNLOAD: Download the FREE 65+ Business Analyst Interview Questions e-book and Resource Guide.

19. 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.

20. 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. According to this rule, a requirement should be:

• Specific: The requirement should be unambiguous and consistent so that it can 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.

21. 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.

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

The configuration management process consists of tools and policies you need to manage ‘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.

23. 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 the 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.

24. 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.

25. Do you follow any verification activities before you extend your requirements documents for 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?

INSTANT DOWNLOAD: Download the FREE 65+ Business Analyst Interview Questions e-book and Resource Guide.

SECTION C: Technical Business Analyst Interview Questions

26. What is a use case?

A use case is a methodology used in requirement analysis to identify, organize and document the requirements.
The 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.

27. 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.

28. 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. 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 [main flow]
• The user clicking the ‘Forgot password’ link [alternate flow]
• The system showing a ‘404 error’ in spite of the user entering the correct username and password [exception flow]

29. 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’.

30. 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 trigger the use cases. Actors are represented as stick figures 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 in lines (solid and dotted) in a use-case diagram.
• Boundary: The boundary represents the scope of the current use case. Anything within the boundary is part of the use case, and anything outside is considered out of scope. A boundary is represented as a box in a use-case diagram.

31. 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.

32. What is use case generalization and actor generalization?

In the context of use case modeling, 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.

33. 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.

34. 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.

INSTANT DOWNLOAD: Download the FREE 65+ Business Analyst Interview Questions e-book and Resource Guide.

35. 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.

36. 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.

37. 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.
• 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.

38. Elucidate the difference between assumptions and constraints

Assumptions are scenarios considered facts while a product is being designed/developed.

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

39. 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 a SWOT analysis is meticulously listing down the below attributes around your project/goal/situation:

• Strengths (qualities)
• 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.

40. 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.

41. 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 the causes of problems as it organizes data into logical segments for better research, comprehension, and communication.

42. 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:

• Flow objects: Events, activities, gateways
• Connecting objects: Sequence flow, message flow, association
• Artifacts: Data object, group, annotation
• Pool and lanes

INSTANT DOWNLOAD: Download the FREE 65+ Business Analyst Interview Questions e-book and Resource Guide.

43. 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.

44. 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

45. 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.

Applications developed through the JAD development approach have higher customer satisfaction and fewer errors as the end user is directly involved in the development process.

46. 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.

47. 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.

48. 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.

49. 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
• Implement
• Manage
• Control
• Improve

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

50. 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.

SECTION D: Agile Business Analyst Interview Questions

51. 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

52. 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 improve the sprint process and deliverables continuously.

INSTANT DOWNLOAD: Download the FREE 65+ Business Analyst Interview Questions e-book and Resource Guide.

53. 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.
• 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.

54. 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.

55. 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.

56. 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).

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.

57. 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.

58. 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

59. 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.

60. 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.

61. 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.

62. 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 on the results from the tracer bullets.

63. What do we mean by the term ‘Impediment’ with reference to Agile?

Impediment denotes the ’cause’ that hinders the team member from working to its fullest capability. 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

64. 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.

65. 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

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

While managing a large project, many requirements are spread across multiple 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 done.

67. 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, representing 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.

INSTANT DOWNLOAD: Download the FREE 65+ Business Analyst Interview Questions e-book and Resource Guide.

Most Viewed Articles

• How to build a professional Business Analyst Resume?
• Key Skills every Business Analyst must know
• Top 10 Business Analyst Interview tips
• 9 Quick communication improvement tips
• Important documents created by every Business Analyst