Instructor: Razvan Radulian

Business Analyst Boot Camp

Posted on October 17, 2020 by -

Part 1: The Business Analysis Profession

It's only in recent years that business analysis has begun to be recognized as a profession in its own right. While people have been performing the Business Analyst role in organizations for several decades, differing definitions of the role abound. We'll start the workshop by exploring some of them, as well as gaining a clear understanding of where the industry appears to be heading and some emerging standards for the profession.

  1. IIBA® and the BABOK®; The PMI® Guide to Business Analysis and the Business Analysis For Practitioners: A Study Guide
  2. What is Business Analysis?
  3. Business and Solution Domains—how they relate
  4. Key roles in requirements development in SDLC and Agile projects
  5. The competencies of the Business Analyst
  6. Distinguishing novice and expert Business Analysts
  7. Effective communication
  8. Six important BA skills

Practice sessions:

  • Business analysis definition
  • Competencies of a business analyst

Part 2: The Business Case for Good Requirements

IT projects have especially high failure rates, and evidence points to problems with defining requirements as one primary cause. This section presents an overview of the challenges inherent in projects in general, and specific problems typically encountered with IT project requirements. We also examine some common terms and concepts in requirements engineering.

  1. What is a good requirement?
  2. Requirements versus design
  3. Requirements attributes—who needs them?
  4. Key practices that promote excellent requirements
  5. The cost of requirements errors
  6. Requirements engineering overview

Practice sessions:

  • Characteristics of good requirements
  • Explore the differences between requirements and design
  • Evaluate requirements for effectiveness
  • Factors to improve project success

Part 3: Foundations of Requirements Development

In order to increase project success, we need to implement a repeatable, scalable strategy for effective business analysis. In this section, we'll explore a framework in which good business analysis occurs and we'll discuss ways to maximize project success using this framework.

  1. Key terms in requirements development
  2. A strategy for analyzing systems
  3. Common requirement-classification schemes
  4. The three levels of a system
  5. Levels and types of requirements
  6. The importance of traceability
  7. Understanding the business context of projects

Practice sessions:

  • Define key terms
  • Use a framework to drive out requirements
  • Types of requirements
  • Classifying stakeholders' input
  • Evaluate a fictitious but realistic organization for project alignment

Part 4: Project Initiation: Eliciting High-level and Mid-level Requirements

What most people think of as business analysis is central to project initiation. Because of the depth of skill these activities require, most Business Analysts demand separate training to develop true mastery. This course module therefore provides an overview and introduction to crucial business analysis activities by demonstrating common tools for identifying and documenting project scope, for modeling current and desired states, and for stakeholder and persona identification. And because effective initiation can lay the foundation for effective use case or user story development, we'll introduce use cases and user stories by identifying them in this module, too. After we've elicited the high-level and mid-level requirements for our project, we want to check to be sure that what we have so far is a good description of the project's scope.

  1. Understanding product vision and project scope
  2. Identifying and describing project stakeholders and personas
  3. Modeling the business
  4. Analyzing the current state and defining the future state
  5. Identifying systems and actors
  6. Determining scope
  7. Understanding and identifying use cases and user stories
  8. Taking the Agile approach: writing user stories
  9. Identifying and defining data
  10. Documenting business rules
  11. Finding quality attributes
  12. Defining and documenting the project scope

Practice sessions:

  • Modeling the business
  • Context diagramming
  • Ways to identify use cases and user stories
  • Brainstorming and chunkifying
  • Roles and Permissions matrix
  • Use case diagramming
  • User stories
  • High-level data definition
  • Entity relationship diagramming
  • Writing business rules and quality attributes
  • Evaluate a Scope Statement

Part 5: Eliciting Detailed Requirements

Savvy business analysts and project team members have a variety of techniques for finding the detailed functional and non-functional requirements on their projects. This section introduces several of the most powerful and effective analysis techniques and discusses their use in requirements elicitation. As various techniques are covered, the workshop explores how to capture and document the requirements, including effective requirements analysis and traceability.

  1. Overview of requirements-elicitation techniques
  2. Decompose processes to lowest levels
  3. Document analysis
  4. Modeling processes to generate interview questions
  5. Interviewing the stakeholders
  6. Documenting the interview and resulting requirements
  7. Adding detail to requirements we already have
  8. Refining and rewriting for clarity

Practice sessions:

  • Elicitation techniques – advantages/disadvantages
  • Process modeling
  • Generating good interview questions
  • Coping with challenging situations
  • Interview simulations
  • Writing new requirements and refining existing requirements
  • CRUD matrix and CRUD functional requirements

Part 6: Improving Requirements Quality

After we've elicited the detailed requirements for our project, we want to analyze and refine the requirements. Writing requirements is one thing—writing "good" or "effective" requirements is another matter. As we are hearing and documenting requirements from our stakeholders, we should be evaluating them for effectiveness and refining/rewriting those that are not. In this section, we'll learn to derive maximum benefit from reviews throughout the life cycle. We'll then take a closer look at the issue of requirements quality, focusing on writing effective requirements through analysis, refinement, and review. Finally, we'll discuss how to document the scope of the project to minimize rework and scope creep.

  1. Requirements quality
  2. Common problems with requirements
  3. Analyze for ambiguity
  4. Requirements inspection, analysis, and improvement

Practice sessions:

  • Analyze and rewrite requirements

Part 7: Documenting Requirements with Use Cases and User Stories

Developing use cases is fairly straightforward, but someone actually has to document the use cases and requirements discovered during the requirements elicitation process. There is also an art to writing user stories and defining acceptance criteria for the requirements. This section of the workshop focuses on how to apply the knowledge you've gained so far to writing use cases and user stories. It also examines more complex aspects of uses cases, including sub-use cases and use-case linkages in larger systems.

  1. Better user stories using the INVEST model
  2. Defining acceptance criteria
  3. Decomposition of user stories
  4. Considering use cases for decomposing user stories
  5. Use case basics
  6. Use cases and requirements
  7. Usage narrative
  8. Anatomy of a fully dressed use case
  9. Writing effective use case narratives
  10. Understanding sub-use cases
  11. Linking use cases for larger or more complex systems
  12. Use case quality
  13. Avoiding common traps and pitfalls

Practice sessions:

  • Write acceptance criteria and perform peer reviews
  • Decompose user stories
  • Write a usage narrative
  • Write a fully dressed use case and perform peer reviews
  • Check use case quality

Part 8: Packaging and Presenting Requirements

Once we've worked with stakeholders to define their functional and non-functional requirements and to document, refine, and organize the requirements, we have to package those requirements into a specification. In addition, most systems also possess a significant number of requirements that aren't necessarily associated with specific business functions. These types of non-functional requirements must also be captured and documented as part of the complete requirement specification. This portion of the Boot Camp covers how to package the requirements into a specification that can be used for system development and testing.

  1. Organizing and packaging requirements
  2. Presenting requirements for review
  3. Baselining the requirements
  4. User story backlog management
  5. Managing requirements changes
  6. Getting to consensus and approval
  7. Conducting formal and informal reviews
  8. Documenting requirements in a Requirements Specification

Practice sessions:

  • Examine and evaluate a sample Requirements Specification
  • Discuss strategies for presenting requirements to stakeholders
  • Review how to determine impact analysis for changes to the requirements
  • Create a personal action plan for success

Applying Enterprise Business Architecture

Posted on October 17, 2020 by -

Part 1: Business Architecture Organizational Maturity & Roles

Organizational and individual expectations will be set for the workshop. The roles and competencies relevant to the business architecture activities will be discussed. Is your organization ready to support the effort?

  1. What to Expect
  2. Enterprise Support
  3. Business Architecture Maturity Levels
  4. Business Architecture Capabilities
  5. Business Analyst and Architect Synergy
  6. What Do Architects Do
  7. More Advanced Competencies

Activity: Competency Assessment

Part 2: Understand the Enterprise & Business Architecture Key Concepts

The value proposition for building a business architecture and industry best practices will be introduced. This information can also be used to sell the business architecture concept to the enterprise.

  1. The Shift: Strategic to Tactical
  2. Part of the Enterprise Architecture
  3. Benefits of Aligning Architectures
  4. What is Business Architecture
  5. Capture the Knowledge in Blueprints
  6. Build Relationship Maps for Decision Making
  7. Outcome Driven Business Architecture
  8. Why Have a Business Architecture?

Activity: Tactical or Strategic, Selling the Business Architecture

Part 3: Bodies of Knowledge and Frameworks

There are many frameworks that exist that can provide guidance for building the business architecture. But what is out there, what are the benefits and challenges of each and how do I know which combination is right for me? We will provide you with guidance to help you make that decision.

  1. Frameworks Overview
  2. Zachman Framework
  3. TOGAF®
  4. DODAF
  5. FEA
  6. Relevant Bodies of Knowledge
  7. BABOK®
  8. BIZBOK®

Activity: Which Framework to Apply

Part 4: Common Architectural Building Blocks

There are some common elements to business architectures regardless of the framework that should be considered. We will step through those elements or building blocks.

  1. Architecture Requirements
  2. Architecture Boundaries
  3. Applying the Context Diagram and Solution Views
  4. Architecture Structure
  5. Which Components, Relationships and Views
  6. Modeling Hints and Tips
  7. Notations and Modeling Languages
  8. BIZBOK®

Activity: Stakeholder Views, Building Blocks Reality Check, Name Two Quiz

Part 5: Set the Stage: Understand the Business

Understanding the business is critical to the business architecture’s success. This needed business information can be presented in different ways. We will look at a few of the most common ways this information is or can be captured and used to build your business architecture.

  1. Needed Inputs to the Business Architecture
  2. Business Model Canvas and Benefits of Asking Business Model Questions
  3. Strategy and Benefits of Asking Strategy Questions
  4. Balanced Scorecard
  5. Business Operating Model
  6. Identifying Business Scenarios
  7. Assess Maturity and Capabilities

Activity: Applying Business Model & Business Operating Model, True or False Quiz

Part 6: Create a Roadmap

There is a general approach to creating a business architecture that we will logically step through, but many elements should still be considered to tailor the approach. We will look at both so you can develop your own roadmap to success.

  1. Architecture Development
  2. Define Boundaries and Analyze Stakeholders
  3. Select Components, Frameworks and Notations
  4. Identify Elicitation, Analysis Techniques and Tools
  5. Why Approaches Vary
  6. Create a Business Case
  7. Present to Management
  8. Presenting Complex Content

Activity: Agenda for Future State Model, Challenge Scenario, Prepare for Building

Part 7: Build the Knowledgebase

  1. Leverage What You Have – Existing Assets
  2. Adding More Models and Maps
  3. Organizational Model
  4. Functional Decomposition Model
  5. Swim Lane and Value Streams
  6. Business Capabilities and Services
  7. Relationship and Alignment Maps

Activity: List Business Capabilities, Which Maps, Pick One Quiz

Part 8: Use the Business Architecture

  1. Business Architecture Engagement Model
  2. Sell to the Enterprise
  3. Adoption Assessment and Organizational Acceptance
  4. Get Others to Leverage the Business Architecture
  5. Quickly Build Trust with Stakeholders
  6. Be an Advisor, Find Opportunities
  7. Connect to Tactical Projects
  8. Reusing Organizational Assets

Activity: Reuse Examples, Lessons Learned

Business Analysis in Agile Projects (ICP-APO)

Posted on October 17, 2020 by -

Part 1: Getting Started

As we get started we will get to know each other and understand the objectives of the course. We will introduce the importance of Conversation in the Agile environment and how the Conversation can be managed for better communication and results. We will model the creation of Working Agreements that contribute to building trust on a team.

  1. Introductions
  2. Course Objectives
  3. Impact of other Domains on Agile Beginnings
  4. The Agile Conversation
  5. Working Agreements

Part 2: Agile Overview

You’ve heard it all before: “Agile means developing software without any documentation. Agile means developers decide on a product’s features. Agile is the same thing as Scrum.” Perhaps you’ve heard the most misleading concept of all: “Agile means we don’t do business analysis anymore.” Nothing could be more false.

Learn what Agile really is, what the variations and hybrids of Agile are, and how business analysis is critical to project success.

  1. Lean Beginnings
  2. Why Agile?
  3. Agile Manifesto & Principles
  4. Agile Practices

Part 3: Building an Agile Team

In Agile the Business Analyst has various possible roles from Voice of the Customer or Product Owner, member of the Customer side team, or member of the Development side team. In this section, we will explore how to create an effective Agile team with an Agile mindset and then see how the Business Analyst fits into this team framework and provides value.

  1. The Team as a System
  2. The Business Analyst

Part 4: Project Initiation

Agile follows an Adaptive, Just-in-Time planning model. In this section, we will learn how Adaptive Planning can better meet the customer’s needs and provide them more value with fewer resources by only elaborating requirements Just-in-Time.

  1. Five Levels of Planning
  2. Vision
  3. Themes & Roadmap
  4. User Roles and Personas

Part 5: Backlog Planning

The Agile vehicle of communicating requirements is the User Story. The Business Analyst is central in the process of writing and elaborating User Stories. This section will help the Business Analyst learn about User Stories and how to write and elaborate good User Stories.

  1. The Product Backlog
  2. Writing User Stories
  3. Guidelines for Good Stories
  4. Acceptance Criteria

Part 6: Managing the Backlog

After User Stories are written, they need to be prioritized and estimated. As part of the Customer side team, the BA has a major role in prioritization. As a member of the Development side team, the BA will contribute to User Story estimation. Both of these come with low cost, low waste techniques that allow us to do this quickly and get on to the important work of implementing requirements.

  1. Prioritization
  2. Estimating

Part 7: Release Planning

The Business needs to know when they will receive product deliverables. In this section, the Business Analyst will learn how milestones are set and how deliverables will be slated for a release with high confidence in meeting dates.

Part 8: Backlog Refinement

Backlog Refinement is where the Business Analyst is really worth their weight in gold. User Stories represent very thin statements of Customer wants and needs but they don’t contain the details until the development team is close to working on them. As the time to work on them approaches, the details need to be filled in and the Business Analyst is the central figure in requirements elaboration.

  1. Agile Documentation
  2. Requirements Elaboration

Part 9: The Iteration

When Requirements are ready to go – ready to go does not mean mountains of documentation. Much of the details are maintained as tacit knowledge with the Business Analyst and the others who have been involved with the Conversation. Continued collaboration is essential to turning what we’ve learned about the needs of the customer into working software. The Business Analyst is always there involved in answering real-time questions from the team.

  1. Iteration Planning
  2. Iteration Execution

Part 10: Inspect and Adapt

Agile is an Empirical Process for developing complex software. Essential to an Empirical Process is feedback loops. Feedback loops can be both formal and more informal. In this section, we will learn about the formal feedback loops that are built into the end-of-iteration timeframe for driving continuous improvement back into the process.

  1. The Iteration Review
  2. The Demo
  3. The Retrospective

Part 11: Agile Adoption

So you want to drive these concepts into your organization as you leave the class and go back to your work. This section will help you do that effectively.