Fundamentals of Business Analysis

Why BA?

2
 Why do projects fail?

Failed Project Factors:

● Incomplete Requirements - 13.1%

● Lack of User Involvement - 12.4%
● Lack of Resources - 10.6%
● Unrealistic Expectations - 9.9%

Challenged Project Factors:

● Lack of User Input - 12.8%

● Incomplete Requirements & Specifications - 12.3%
● Changing Requirements & Specifications - 11.8%

Source: The Standish Group Report CHAOS, 2014 3

 How to improve ROI?

Reduce
Costs
- Rework
- Mix up
- Cost - Effective
Solutions

Increased ROI

(Return of investment)

Increase
Benefits
- Discover new
needs
- Effective
change
management
- Scale IT

4
 Who?

„Out of chaos, we create order.

Out of disagreement, we create alignment.
Out of ambiguity, we create clarity.

But most of all, we create positive

change for the organizations we
serve.”
Business Analyst Manifesto

5
Competencies of a BA

6
Stakeholders

7
What?

8
 How?

Strategic analysis
Requirements
Other investigation Business case
engineering
techniques

9
Strategic analysis techniques

10
Investigation techniques

11
Business case

12
Requirements engineering

13
 Principles that underpin business
analysis

● Root causes, not symptoms;

● Business improvement, not IT change;

● Options, not solutions;

● Feasible, contributing requirements, not all requests;

● The entire business change lifecycle, not just requirements

definition;

● Negotiation, not avoidance;

● Business agility, not business perfection.

14
The competencies of a Business
Analyst
The competencies of a BA in a nutshell

16
Analytical thinking and problem solving

17
 Analytical thinking and problem solving
Dos & Don’ts

• Identify and challenge • Accept the initial framing of

assumptions; a problem;
• Articulate and address the • Make decisions based on
conflicts between the goals preconceived notions;
and objectives of the • Place greater weight on
stakeholders; evidence that confirms
• Understand how a change to existing impressions.
a component affects the
system as a whole.

18
Behavioral characteristics

19
 Behavioral characteristics
Dos & Don’ts

• Identify when an ethical • Hide/mask potential conflicts

dilemma occurs; Discuss it of interest;
openly. • Hide potential delays/issues
• Store or file the information in until the last moment;
a way that enables to retrieve • Engage with the stakeholders
it at a later date; desires, not with the
• Honestly address issues when stakeholders needs.
they occur.

20
Business knowledge

21
 Business knowledge
Dos & Don’ts

• Understand the relevant • Neglect business environments,

regulatory, compliance, and operations, process and
governance frameworks; practices relating to: common
• Know the major customer business management and
segments, the common decision making concepts,
products, the product types, principles activities and
the competitors and partners practices;
of the organization; • Be affraid to recommend
• Identify experts; changes to an ongoing change
• Understand what additional initiative in order to respond to
capabilities are present, but a volatile business
not fully used, in a solution environment.
that can be deployed to
provide business value.
22
Communications skills

23
 Communications skills
Dos & Don’ts

• Communicate in a calm and • Neglect the impact of tone

rational manned when faced and how it can positively or
with critical or urgent negatively influence the
situation; bring solutions to listener;
the table; • Forget to verify if the
• Use visual aids to help the audience has understood the
audience better understand; information that has been
• Proper use of grammar and presented;
style; • Use an interpretative choice
• Effectively paraphrasing of words.
statements to ensure
understanding.

24
Interaction skills

25
 Interaction skills
Dos & Don’ts

• Encourage stakeholders to • Avoid team conflicts: if handled

reach win/win outcomes on a well, the resolution of conflict
regular basis; can actually benefit the team;
• Understand and consider all • Ignore the individual needs and
parties interests, motivations capabilities of each team
and objectives; member and stakeholder and
• Paint a clear picture of a how those can be most
desired future state; Always effectively channeled in order
have a clear goal so the team to reach the shared objectives.
can push together towards it.

26
Software application

27
 Software application
Dos & Don’ts

• Choose the right tool for the • Forget about traceability

job; • Save locally, make sure the
• Use different kind of tools in documents are available for
order to benefit from all; the whole team
• Learn how to use most of the
major features of the tool.
Stop learning ☺

28
Requirements engineering
 Context
● What is a requirement?
● What is the meaning and purpose of requirements?
● How do you figure out what the requirements should be?

30
 Requirements engineering

Requirements engineering

Requirements
Requirements Development
Management

Validation Change
Elicitation Analysis Negotiation Specification Traceability
Verification Management

31
 Requirements Elicitation

The process of discovering the requirements for a system by

communication with customers, system users and others who have
a stake in the system development.

Identify relevant requirements sources.

Ask them appropriate questions to understand their needs.

Look for implications, inconsistencies, and unresolved issues

Goals
in gathered information.

Confirm your understanding of requirements with the users.

Synthesize appropriate statements of the requirements.

32
 Requirements Elicitation
Techniques

Questionnaire

Prototyping Interviewing

Requirements
Role Playing
Workshops

Use cases Brain storming

33
 Requirements Analysis

The process of breaking down user requirements into their

components and studying these to develop a set of system
requirements.

Achieve agreement among developers and customers.

Goals Provide a basis for design.

Provide a basis for Verification and Validation (V&V).

34
 Requirements analysis and modeling
Techniques

• the trigger or business event that initiates the task;

• inputs to the task, including perhaps the trigger and

UML probably also other;

• information that is required to carry out the task;

• outputs from the task;

• costs relevant to this particular task;

BPMN
• measures and standards applicable to the task;

• a detailed breakdown of steps within the task;

• business rules to be followed in performing the task.

35
 Requirements filters
Checking for
overlapping or
duplicate
requirements
Unravelling
Confirming
multiple
quality
requirements

Checking for Necessity

solutions checking

Removing Feasibility
conflicts evaluation

36
 Requirements Negotiation

The process of agreement on a deliverable system that is

realistic for developers and customers. The team and other project
stakeholders negotiate the priority, availability, and cost of each
requirement.

Identify the key stakeholders.

These are the people who will be involved in the negotiation

Determine each of the stakeholders “win conditions”

Goals
Win conditions are not always obvious

Work toward a set of requirements that lead to “win-win”

37
 Requirements Specification

Complete description of the behavior of the system to be

developed.

Establish agreement between stakeholders

Firm foundation for design

Reduce development effort

Goals Provide a basis for estimating cost and schedule

Reduce rework effort and cost of quality

Provide a baseline for validation and verification

Serve as a basis for enhancement

38
 Requirements verification
and validation

Verification: „Am I building the product right?”

Proving that each requirement has been satisfied.

Verification It can be done by logical argument, inspection, modeling,

simulation, analysis, expert review, test, demonstration.

Validation: „Am I building the right product?”

Ensuring that the set of requirements is correct, complete

and consistent.
Validation Ensuring that a model can be created that satisfies the
requirements.
Ensuring that a real-world solution can be built and tested
to prove that it satisfies the requirements

39
 Requirements Management

The process of documenting, analyzing, tracing, prioritizing and

agreeing on requirements and then controlling change and communicating
to relevant stakeholders. It is a continuous process throughout a project.

Understand relationships among key stakeholders and involve

them

Identify change in requirements

Goals Managing and controlling requirements changes

Identify and track requirements attributes

Trace requirements

40
 Requirements Traceability

The ability to describe and follow the life of a requirement, in

both forwards and backwards direction (i.e. from its origins, through
its development and specification, to its subsequent deployment and
use, and through all periods of on-going refinement and iteration in
any of these phases).

To ensure the object of the requirements conforms to the

requirements by associating each requirement with the object
via the traceability matrix.
Goals Concerned with documenting the life of a requirement.
To find the origin of each requirement and track every change
which was made to this requirement
Agile Scrum Methodology
What Is Scrum and Agile?

Scrum

DSDM XP

Agile

Crystal FDD

● XP - Extreme Programming;
AUP ● DSDM - Dynamic Systems Development;
● AUP - Agile Unified Process;
● FDD - Feature Driven Development
43
Scrum Roles

Scrum team

Product Development
Owner Team

Scrum
Master

44
Product owner

● Clearly expressing Product Backlog items;

● Ordering the items in the Product Backlog to best

achieve goals and missions;

● Optimizing the value of the work the Development

Team performs;

● Ensuring that the Product Backlog is visible,

transparent, and clear to all, and shows what the
Scrum Team will work on next; and,

● Ensuring the Development Team understands

items in the Product Backlog to the level needed.

45
Development team

● Teams are self-organizing;

● Cross-functional;

● Accountability belongs to the Dev Team

as a whole;

● Membership should change only between

sprints;

● Scrum recognizes no sub-teams in the

Dev Team.

46
Scrum Master

● Servant Leader;

● Monitoring and Tracking;

● Reporting & Communication;

● Process check master;

● Resolves impediments and conflicts;

● Shields the team;

● Improvement.

47
 Scrum Events

Planning

Daily
Scrum • No changes are made that would endanger the
Sprint Goal;

Sprint
• Quality goals do not decrease; and,

• Scope may be clarified and re-negotiated between

the Product Owner and Development Team as
more is learned.

Review

Retrospective

Refinement/
preparation

48
 Sprint planning

Who?
• Development Team;
• Scrum Master;
• PO.

What?
• Discuss top priority product backlog items;
• Scrum team selects what items to do, tasks are indentified
and each is estimated.

Why?
• Know what will be worked on;
• Understand it enough to do it;
• High-level design is considered. Sprint backlog

Sprint goal

49
 Daily Scrum

Who?
• Development Team.
• Others without disrupting(PO, Arhitect, UX designer)

What?
• What did I do yesterday that helped the Development Team meet the
Sprint Goal?
• What will I do today to help the Development Team meet the Sprint
Goal?
• Do I see any impediment that prevents me or the Development Team
from meeting the Sprint Goal?

Why?
• Not for problem solving; Impediments
• These are not status for the Scrum Master/PO;
• Improve communications;
• Eliminate other meetings.
Commitments

50
 Sprint Review

Who?
• Scrum team;
• Interested stakeholders;

Why?
• To demonstrate completed work and gather
feedback;
• To inspect and adapt the product backlog.
When?
• At the end of each sprint.

Revised product
backlog

51
 Sprint Retrospective

Who?
• Scrum team.

Why?
• Inspect how the last Sprint went with regards to people,
relationships, process, and tools;
• Identify and order the major items that went well and
potential improvements;
• Create a plan for implementing improvements to the way the
Scrum Team does its work.

When?
• At the end of each sprint. Identify
improvements

52
Scrum Artifacts

Product
Backlog

Burn-
Sprint
Down
Backlog
Chart

Scrum
artifacts

Sprint
Increment
Goal

Definition
of “Done”

53
 Product backlog

● Only entries that add value;

● Up to date document;

● Different level of details;

● No tasks;

● Ordered Product Backlog;

● Accessible;

● Continuously evolving.

54
 Slicing the Cake

• can’t go into production with screens, • there is no UI, SOA, or data team,
services, or well normalized database you're all on the same team
schemas
• focused on delivering a suite of
• when all the layers are hooked up do features for the customer
they offer any value?
• no need to negotiate for resources
• until you integrate every thing
together, you really haven’t delivered • reduce the effort that comes from
anything of value trying to coordinate activities across
the

55
 Task vs spike vs improvement

Tasks: decomposed parts of a story that get into the HOW the story will
be completed;

Improvements: cards to represent work like refactoring, or non-user

exposed technical tasks that don't relate to a specific user story;

Spikes: a time-boxed research activity;

56
 Sprint Backlog

Items from
Tasks To Do Doing Done
product backlog

Task
T#1.4 T#1.5 T#1.3 T#1.2 T#1.1
#1.1
Item #1

T#2.3 T#2.2 T#2.1

Item #2

T#3.3

Item #3
T#3.2 T#3.1

57
 Increment

Product
Product
backlog Product
backlog Product
backlog Product
backlog backlog

Sprint Sprint Sprint Sprint Sprint Sprint

#1 #2 #3 #4 #6 #7

Product
Increment
Product
Product Product
Increment
Increment Increment Product
Increment

58
Definition of “Done”

There should be a
shared understanding
of what it means for a
piece of work to be
“Done”. This definition
of “Done” must be
discussed and agreed
upon by the Scrum
Team at the beginning
of the project so that
future Increments
would be releasable.

59
 “Assumptions will get you killed”

DoR DoD

•User Story is clear • Code produced

•User Story is testable • Code commented
•User Story is feasible • Peer reviewed
•User Story defined • Builds without errors
•User Story Acceptance Criteria defined • Unit tests written and passing
•User Story dependencies identified • Deployed to system test environment
• Passed system tests

60
Monitoring Progress towards a Goal

61
 Monitoring Sprint Progress

Sprint Goal Tasks To Do Doing Done

T#1.4 T#1.5 T#1.3 T#1.2 T#1.1

The goal of this sprint is to
...

T#2.3 T#2.2 T#2.1

T#3.3

T#3.2 T#3.1

62
 Product ownership
(vision, strategy, roadmap)
 Context

Vision
Product owner:
Strategy

An idividual who owns the product on

behelf of the organization. Tactics

Product:
Addresses a problem or
provides a benefit to a Generates revenue, helps
group of people. sell another product or a
service, or serves another
business goal.

64
 Product Ownership

•Manage the stakeholders

Collaboration •Joint backlog grooming
•Joint meetings

•Personas
Market •Feedback
•Exposing increments to users

•User stories and sketches

Features/ UX •Product backlog
•Product canvas

•Business model
Value •Revenue sources, cost
•Structure, channels

•Vision and roadmap

Ownership •Empowerment
•Budget

65
 Product vision

Why vision statements are so important?

People always have an idea in their head, but is it the

same as yours?

Know where you are going

Vision
Create the same product

66
The product vision board

Source: Roman Pichler 67

 Tips

Describe the Motivation

Look beyond the Product
behind the Product

Distinguish between Vision

and Product Strategy

Employ a Shared Vision Choose an Inspiring Vision

Think Big

Keep your Vision Short Use the Vision to Guide

and Sweet your Decisions
69
 Product strategy

Market and
needs

Product
Strategy
Stand-out Business
features benefits

70
Strategy focus and inflection points

71
 The Product Strategy in context

Vision

Product
Strategy

Product
Roadmap

72
Build-Measure-Learn

1. Select the 2. Decide how

biggest risk to address it

4. Analyze
3. Collect the
and make
data
changes

73
Product roadmap

Provides a
continuity of
purpose

Facilitates
stakeholder
collaboration

Helps with
prioritisation

Unburdens the
product
backlog

Helps acquire
a budget

Supports
portfolio
management
74
Product roadmap - Template

75
Product roadmap - Example

76
 Product Roadmap – Product Backlog

Strategic: Tactical:
Goals, dates, User stories, UI
metrics design etc.

77
Top-down/Bottom-up

Top-down

Bottom-up

78
 Review the roadmap

Mature Review every

Review quarterly
product 3 to 6 months

Young Review monthly

Review quarterly
product

Dynamic market Stable market

79
Product backlog
 Context

As a PO, I want to understand the Product Backlog so that I can build a

better product and deliver the most value quickly

81
Product Backlog Example

82
Agile WBS
(Work breakdown structure)

83
DEEP

Detailed
Appropriately

Prioritized
Estimated

Emergent

84
PBI - Product Backlog Item

85
 INVEST – Good quality PBI

• Independent (of all others)

• Negotiable (not a specific contract for features)

• Valuable (or vertical)

• Estimable (to a good approximation)

• Small (so as to fit within an iteration)

• Testable (in principle, even if there isn't a test for it yet)

86
 Prioritization
What may influence a product owner's prioritization?

Value

Effort

87
Keeping the backlog healthy

✓ Regularly maintain
✓ Review the backlog before each iteration
✓ "backlog grooming" in agile circles

88
 Progressive Refinement

● If PO try to keep all requirements details at the same level:

• We need to have estimate all requirement's details at first of project

while our knowledge about project is minimum.

• It cost a lot of time and energy to estimate requirements that maybe

never made in future.

• It produces large product backlog that refining it on future is not easy.

• We are missing a conversation chance because all requirements were

completed before.

So JUST IN TIME & JUST ENOUGH

89
 Backlog Grooming

What is it?
Add PBI
Complete PBI
Estimate
Ordering
Prioritize

By who?
A joint and continuous activity, guided by product owner and scrum
team effective participation. As general rule, development team help
product owner on backlog grooming in 10% of sprint.

When?
When it is needed. Usually once on each sprint.

90
PBI Estimations

91
 Anti-patterns to watch for

● The product owner prioritizes the backlog at the start of the project,
but doesn't adjust it as feedback rolls in from developers and
stakeholders;

● The team limits items on the backlog to those that are customer-
facing;

● The backlog is kept as a document stored locally and shared

infrequently, preventing interested parties from getting updates.

92
 Tips

Tip #1: Complement

your Product Backlog
with a Product Roadmap

Tip #2: Focus your

Backlog on the Next
Major Release

Tip #3: Start with a

Short and Sketchy
Product Backlog

Tip #4. Collaborate with

the Development Team

Tip #5: Say No

93
 Tips

Tip #6: Look beyond

User Stories

Tip #7: Priorities your

Backlog

Tip #8: Proactively

Manage your Product
Backlog

Tip #9: Get the

Backlog Ready

Tip #10: Make your

Product Backlog Visible
and Easily Accessible

94
 Until next time

Reference:
• Business Analysis 2nd edition by Debra Paul (Editor),
Donald Yeates (Editor), James Cadle
• A Guide to the Business Analysis Body of
Knowledge® (BABOK® Guide)
95