The document discusses the cause and effect diagram, also known as the Ishikawa or fishbone diagram, which categorizes potential causes of a problem to identify reasons for a process failure. It highlights the importance of this visual tool in brainstorming sessions for better group participation and understanding of the problem. Additionally, it contrasts traditional and agile business analyst approaches to requirements documentation and emphasizes the importance of collaboration between business analysts and development teams.

1. Cause
and
Effect Diagram
(Professional Business Analyst Training organisation)

2. •Cause and Effect diagram devised by Professor Kaoru
Ishikawis also known as Ishikawa diagram or Fishbone
diagram. This diagram helps to categorize all possible
causes of a specific problem, and identify the reason
for a process not working out.

3. •This is one of the great visual tools to use during
brainstorming session to focus on the conversation and
help the group to determine important causes with more
detail. The diagram resembles the skeleton of a fish and
hence the name ‘Fishbone diagram’ is given.

4. Why use Cause and Effect diagram?
· Easy to read format to draw out cause and effect
relationships in an orderly manner.
· Recognizes areas of collecting information.
· Increase process knowledge.
· Group participation is encouraged to gather data.

5. Traditional BA (Waterfall) Agile BA
Requirements are documented in Use
Cases,Business Requirements, Functional
requirements, UI Specifications, Business Rules.
Requirements are documented in Epics, User
Stories and optionally Business (or Essential) Use
cases.
Focuses on completeness of requirement and
spends time in ensuring the requirement is
unambiguous and has all the details.
Focuses on understanding the problem and being
the domain expert so that s/he can answer
questions from the development team swiftly and
decisively.
Focuses on getting a ‘sign off’ on the requirements.
Focuses on ensuring the requirements meet the
currentbusiness needs, even if it requires
updating them.
Often there is a wall between the BA/Business and
the Development team.
Agile BA (Often called as Product Owner) is part of
the team.
Tends to dictate solutions.
Has to remain in the problem domain, leaving the
development team ‘space’ to explore different
solutions.
Long turnaround. Quick turnaround.
Focus on what the requirements document said. In
other words, output (Artifact) is a well written
thorough requirements document.
Focus on the functionality of the developed
software. In other words, output (Artifact) is the
software that meets thebusiness needs.

6. Steps for constructing Cause and Effect diagram
· Identify the problem to be analyzed which is the head.
· Create a problem box displaying the problem and draw
spine (draw horizontal arrow pointing to the right).
· Identify the main causes contributing to the problem.
These causes are displayed as arrows to the spine similar
to the bones of the fish. .

7. · Sort out other causes influencing the problem (effect).
· Analyze the diagram to determine the root cause.
Hence, Cause and Effect diagram drives out all the causes
of a problem using the 5 W’s (when, where, why, who,
what) to provide an effective solution.