Summary
This video comprehensively covers the business analyst role, detailing its definition, typical organizational placement, and various associated roles. It emphasizes essential skills such as translation, detective work, engineering, and politicking, alongside soft skills like comprehension, adaptability, problem-solving, and communication. The content also delves into practical techniques for root cause analysis, requirements gathering (interviews, workshops, surveys, shadowing, prototyping, document analysis), and decision-making, along with essential diagramming types (system, state, ERM, business process) and structuring requirements effectively using a hierarchical approach and templates.
Key Insights
Business analysis is defined as enabling enterprise change by defining needs and recommending value-adding solutions.
Based on the IIBA's Business Analysis Body of Knowledge, business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. An example is needing an umbrella during heavy rain to stay dry.
A crucial BA skill is translation, bridging communication gaps between business and IT departments.
Business Analysts must act as translators, speaking both business and IT 'languages' to ensure clear communication and that software development aligns with business value.
Step 1: Understand the 'real' problem, not just the stated symptom, by asking 'why'.
The first step is to define the problem accurately. Asking 'why' multiple times helps to broaden the perspective beyond the initial narrow problem statement, revealing the true underlying issue.
The common '5 Whys' approach is flawed due to its linear nature and bias; a logic tree is superior.
A linear '5 Whys' approach often leads to biased or incomplete root cause identification. Using a logic tree allows for multi-dimensional thinking, exploring all branches and avoiding getting stuck on a single path.
Shadowing offers a real-life perspective by observing users in their natural work environment.
Accompanying a user reveals 'silent requirements' – needs so obvious to the user they're not articulated. It's time-consuming but provides invaluable firsthand insights.
Business Process Diagrams (BPD) are dynamic, showing a timed sequence of activities, decisions, and endpoints.
BPDs model processes chronologically from start to end, clearly showing activities, decision points (like credit score checks), and outcomes, providing a dynamic view unlike static diagrams.
Sections
Understanding Business Analysis and Roles
Business analysis is defined as enabling enterprise change by defining needs and recommending value-adding solutions.
Based on the IIBA's Business Analysis Body of Knowledge, business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. An example is needing an umbrella during heavy rain to stay dry.
Organizations typically have distinct business and IT sides, with business analysis bridging the gap.
Organizations are structured with a business side (users generating revenue) and an IT side (hardware, infrastructure, developers). The business analysis spectrum sits between these two extremes.
Various roles like Systems Analyst, Process Analyst, and Product Owner fall under the business analysis umbrella.
Roles such as Systems Analyst, Process Analyst, Product Owner, IT Business Analyst, and Requirements Engineer are described. Systems and Process Analysts are more IT-related, while traditional Business Analysts and Product Owners (depending on the product) are more business-focused.
IT-focused BAs translate requirements into IT language; business-focused BAs gather needs from end-users.
IT-related roles like IT Business Analyst or Requirements Engineer translate requirements into IT language. Business-focused roles, like traditional Business Analysts or Product Owners, talk to end-users to gather needs, focusing on 'what' and 'why'.
Product Owners focus on user needs and write user stories; Systems Analysts focus on system needs and implementation.
Product Owners focus on user requirements, writing user stories and acceptance criteria. Systems Analysts focus on system requirements, determining how systems must change to implement user requirements.
Essential Business Analyst Skills
A crucial BA skill is translation, bridging communication gaps between business and IT departments.
Business Analysts must act as translators, speaking both business and IT 'languages' to ensure clear communication and that software development aligns with business value.
Being a detective BA involves asking the right questions to uncover real needs and prevent scope creep.
Like a detective, a BA must ask probing questions to understand stakeholders better, expose real needs, avoid unnecessary features, make flaws visible, and ensure transparency.
An engineer's skill set is needed to precisely document requirements in IT language using models and diagrams.
BAs need engineering skills to precisely document requirements in IT-friendly terms using models and diagrams like use case diagrams, class diagrams, and process models. Plain text is insufficient for detailed engineering.
Political skills are essential for navigating stakeholder conflicts, dependencies, and negotiations.
BAs must be politicians to manage discussions, resolve dependencies and conflicts among stakeholders, negotiate priorities, and ensure goals are met despite challenges.
Comprehension and adaptability are vital for quickly learning new business domains and adjusting to change.
BAs must quickly gain knowledge in new industries or project contexts and adapt to new stakeholders, environments, and complex changes to thrive.
Problem-solving and analytical skills are core to a BA's role in enabling change and analyzing data.
BAs need to break down problems, analyze data, identify patterns and root causes, and move from an 'as-is' state to a 'to-be' state by implementing solutions.
Effective communication is key to convincing diverse stakeholders and settling disputes.
BAs must communicate effectively across different stakeholder levels and expertise, convincing them of proposed solutions and settling disputes during workshops or discussions.
Root Cause Analysis Techniques
Step 1: Understand the 'real' problem, not just the stated symptom, by asking 'why'.
The first step is to define the problem accurately. Asking 'why' multiple times helps to broaden the perspective beyond the initial narrow problem statement, revealing the true underlying issue.
Classify problems into simplistic, deterministic, random, or indeterminate types for appropriate analysis.
Problems can be categorized as Simplistic (easy answer), Deterministic (formula-based), Random (multiple possible answers, judgment needed), or Indeterminate (multiple unidentified answers, significant judgment needed). This video focuses on indeterminate problems.
Use a logic tree and divergent thinking to identify problem components and potential root causes.
A logic tree breaks down a problem into parts, progressively refining branches to identify leaves as potential root causes. Divergent thinking generates many ideas, bold or chaotic, without initial evaluation.
Formulate and prioritize hypotheses based on potential root causes identified in the logic tree.
Hypotheses are assumptions about root causes that can be disproven by evidence. They should be prioritized based on perceived probability or impact, focusing on the 20% of causes likely driving 80% of symptoms.
Gather data to test hypotheses, using a matrix to find assumptions least inconsistent with evidence.
Collect relevant data and evidence for each hypothesis. A hypothesis-evidence matrix helps identify which hypothesis is best supported or least contradicted by the gathered information.
Identify action items and create a plan to address the confirmed root cause and resolve the problem.
Once a root cause is identified through evidence, develop actionable steps and a plan to implement solutions, addressing the cause to resolve the overall problem.
The common '5 Whys' approach is flawed due to its linear nature and bias; a logic tree is superior.
A linear '5 Whys' approach often leads to biased or incomplete root cause identification. Using a logic tree allows for multi-dimensional thinking, exploring all branches and avoiding getting stuck on a single path.
Requirements Gathering Techniques
Document analysis is a foundational technique for building baseline knowledge of a system or project.
Reviewing existing documents (requirements documents, etc.) is often the first step. It provides a baseline understanding but lacks interactivity for clarification.
Surveys and questionnaires efficiently gather standardized data from a large audience.
Surveys collect data through standardized questions, ideal for high volumes of information. However, designing unbiased questions and lack of immediate clarification are drawbacks.
Shadowing offers a real-life perspective by observing users in their natural work environment.
Accompanying a user reveals 'silent requirements' – needs so obvious to the user they're not articulated. It's time-consuming but provides invaluable firsthand insights.
Interviews are crucial for gaining specific details and immediate feedback through interactive Q&A.
Interviews allow for deep dives into requirements with instant feedback and follow-up questions, essential for capturing specific needs.
Workshops involve multiple stakeholders collaborating to specify requirements, fostering higher acceptance.
Workshops bring several stakeholders together to work on requirements, increasing the chance of comprehensive coverage and stakeholder buy-in, but can be costly and time-consuming.
Prototyping provides tangible increments for feedback, useful for clarifying unclear requirements.
Building and showing an increment of the product allows stakeholders to visualize and provide feedback, facilitating an iterative process especially for unclear requirements.
Personal recommendation: Start with document analysis, prioritize interviews, use workshops for complexity, prototyping for clarity.
A recommended approach starts with document analysis, followed by interviews as the main technique. Workshops are for complex or inconsistent requirements, and prototyping is for unclear requirements needing frequent feedback.
Effective interview structure involves kickoff, goal setting, active listening, and documentation.
Interviews should start with understanding the core problem, set clear goals for the session, actively listen for keywords, ask 'why' to understand intent, repeat and document requirements, and keep the end goal in mind.
Transforming user needs into user stories with clear acceptance criteria is fundamental in Agile projects.
User stories follow 'As a [role], I want to [capability] so that [benefit]' and must be backed by specific acceptance criteria defining when the requirement is met.
Clarifying terms and translating business language into technical requirements is a key BA function.
Business terms need clarification through document analysis and interviews. Then, business language requirements (like acceptance criteria) are translated into technical language developers can implement.
Every requirement must have a corresponding test case to ensure verifiability and quality.
Test cases are essential for verifying that implemented requirements function as expected, ensuring the solution meets the defined criteria.
Writing and Structuring Requirements
Bulletproof requirements are atomic, complete, consistent, concise, feasible, unambiguous, understandable, and testable.
These criteria ensure requirements are well-defined and usable for development. Each requirement should stand alone, have no gaps, agree with others, be brief, realistic, clear, easily understood, and verifiable.
The Girkin format (Given, When, Then) provides a structured way to write testable requirements.
Girkin uses a syntax: 'Given [precondition], when [condition met], then [system behavior].' For example: 'Given the user clicked buy, when successful, then notify user fast.'
Making requirements unambiguous requires asking targeted 'W' questions (Who, How, Where, What, When).
To ensure clarity and remove ambiguity, ask Who (the actor), How (the mechanism), Where (location), What (the message/outcome), and When (timing) for each requirement.
Requirements exist in a hierarchy: Business Need -> Business Requirements -> Stakeholder Requirements -> Solution Requirements (Functional/Non-functional).
This hierarchy structures requirements from high-level business goals down to specific functional and non-functional details. Transition requirements are temporary needs like training.
Utilize Excel templates with attributes like ID, Title, Description, Source, Owner, Priority, Status, and Acceptance Criteria for managing requirements.
An Excel spreadsheet can serve as a robust tool for capturing requirements, their attributes, and tracking their status. Key columns include a unique ID, title, description, source, owner, priority, due date, status, acceptance criteria, and parent requirement linkage.
A business need, like regulatory compliance, drives the entire requirements hierarchy and project scope.
Every project begins with a business need, such as adapting to new government regulations to avoid fines. This need filters down through business requirements, stakeholder requirements, and finally solution requirements.
Essential Diagrams for Business Analysts
System diagrams illustrate system architecture and interconnections, showing dependencies and impacts of changes.
System diagrams map out how different systems and applications are structured and connected, helping to understand the impact of changes in one component on others.
State diagrams define possible states of a data object and transitions between them, ensuring valid workflows.
State diagrams show the lifecycle of an object (e.g., a bank account) and the allowed transitions between its various states (e.g., active, inactive, closed).
Entity Relationship Models (ERM) depict how entities (data objects) relate to each other, crucial for database design.
ERMs illustrate entities, their attributes, and the relationships (one-to-one, one-to-many, many-to-many) between them, essential for understanding data structures.
Business Process Diagrams (BPD) are dynamic, showing a timed sequence of activities, decisions, and endpoints.
BPDs model processes chronologically from start to end, clearly showing activities, decision points (like credit score checks), and outcomes, providing a dynamic view unlike static diagrams.
Ask a Question
*Uses 1 Wisdom coin from your coin balance
