Any interested Business Analyst in Agile Framework would discover what is the essence of Agile philosophy and how to adopt it`s values in the team and shed light on the other philosophies and their primary focus and methods, then demonstrate what is the practice of business analysis, why having a business analyst in Agile team, what to expect from this role, and the main characteristics and attributes of good BA. closing with the most effective way to define the requirements using Behaviour Driven Development (BDD) method.

1. BUSINESS ANALYSIS: AGILE
PHILOSOPHY

2. ATTITUDE || PROCESS
Agility is

3. ENVIRONMENT || METHODOLOGY
Agility is

4. THE PHILOSOPHY CENTERS
AROUND THE AGILE MANIFESTO
➤ Individuals and interactions over Processes and tools
➤ Working software over Comprehensive documentation
➤ Customer collaboration over Contract negotiation
➤ Responding to change over Following a plan

5. AGILE IS NOT A NOUN : BEING
AGILE
➤ Optimise value and eliminate waste, hands-off, delays.
➤ Inspire and empower the team.
➤ Deliver fast.
➤ Build quality in.
➤ Amplify learning, get feedback early.

6. WASTES IN BUSINESS ANALYSIS
Requirements Completed,
Not Implemented
Defining Features
Customers Do Not Use
Working Without a Common
Understanding
Doing Things That Do Not
Add Value
Moving To The Next Task
Without Focus

7. FOUR PHILOSOPHIES DOMINATE
CURRENT IT DEVELOPMENT
Philosophy Primary Focus Primary Methodology
Lean Eliminate Waste Kanban
Agile Software Production Scrum
Continuous Delivery Continuity DevOps
Continuous Integration Software Quality TDD/BDD

8. BUSINESS ANALYSIS?!
what is

10. BUSINESS ANALYST?!
why have a

11. STAKEHOLDERS CAN'T
DEFINE THEIR OWN
REQUIREMENTS

12. DEVELOPERS CAN'T
ELICIT REQUIREMENTS
Communication and modeling skills are necessary to elicit
requirements effectively.

13. YOU NEED ANALYSIS
EXPERTS

14. BUSINESS ANALYST DO?!
what does the

15. EXCELLENT REQUIREMENTS
ELICITATION

16. GET EVERYONE ON THE
SAME PAGE.
Use effective ways to

17. PROTOTYPING
Visual models show how requirements translate into functionality;

18. USER EXPERIENCE
Allow users to efficiently utilize all features of a product

19. USER-CENTERED DESIGN
PROCESS
RESEARCH.
User Needs
Business Needs
Prioritization
DESIGN.
Information Architecture
Interaction Design
Visual Design
EVALUATION.
Testing
Review

20. THE KEY PRINCIPLES OF DESIGN
PROCESS
➤ Get Feedback Early by Showing Prototypes. fail fast.
➤ Turning a Concept into Something More Tangible.
➤ Bias Toward Action.
➤ Radical Collaboration of Cross-Functional Teams.

21. MODELING
Keep everyone speaking the same language by

22. ACT AS BUSINESS COACH
Translate “business speak” into “technical speak” and vice versa

23. EFFICIENT COMMUNICATION
Deliver your message clearly in the shortest amount of time.

24. BUSINESS ANALYST?!
what is the characteristics of an agile

25. ANTICIPATION
Things created twice, first visually and conceptually then physical

26. INNOVATION
Look for new approaches to solve a problem.

27. FLEXIBLE
There is always more than one way of doing things

28. COLLABORATIVE
Work together as a team, not as a group of individuals

29. GENERAL SPECIALIST
It is all about productivity!

30. DOMAIN KNOWLEDGE
use that knowledge to elicit requirements, analyze the information
elicited to proffer recommendations.

31. ANALYTICAL SKILLS
Tools and methods.

32. AND MORE ,,
➤ Requirement Elicitation.
➤ Problem Solving.
➤ Critical Thinking.
➤ Detail oriented.

33. AGILE BUSINESS ANALYSIS
Practicing

34. CONVENTIONAL REQUIREMENTS
Business Requirements (Goals and
Objectives benefiting the organization).
Product will increase our customer base
by 20% by the end of the fiscal year.
Business Requirements

35. CONVENTIONAL REQUIREMENTS
Stakeholder Requirements (Needs of
individuals or a group).
As a website visitor, I can order any
product in Vigintrees`s catalog directly
from the site to reduce ordering time.
Business Requirements
Stakeholder Requirements

36. CONVENTIONAL REQUIREMENTS
Business Requirements
Stakeholder Requirements
Solution Requirements (Functional and
Non-Functional details).
Functional: “calculate product price
including fees and taxes”
Non-Functional: “Average response time
will be less than 3 seconds”
Solution Requirements

37. REQUIREMENTS CONSTRUCTS IN
AGILE ENV.
Epics
User Stories
Scenarios
Business Rules
Constraints

38. CHARACTERISTICS OF A GOOD
USER STORY.
A. Independent
B. Negotiable
C. Valuable to users or customers
D. Estimatable
E. Small
F. Testable.

39. EVOLUTION OF REQUIREMENTS
Should we fund
this product?
One Big Thing,
Vision Statement
Project Charter
Business Requirements
What will the product
do for us?
Epic, User Story
Does the product
do it right?
Scenario,
Business Rule
CONVENTIONAL
Test Plans
Test Scenarios
Test Cases
Stakeholder Requirements
Solution Requirements

41. High-priority features should be small and contain sufficient detail.
Product backlog has to be progressively refined over time.
Who knows what under the waterline and things will change.

42. GROOMING THE PRODUCT
BACKLOG

43. THE GROOMING STEPS:
Step 1:Analyze the Data.
Step 2:Decide what to do Next.
Step 3:Refine the Backlog Items.
Step 4:Get the High-Priority Items Ready “DEEP”,
“Prioritised”.

44. TIPS:
#1: Complement Product Backlog with a Product Roadmap
#2: Focus your Backlog on the Next Major Release.
#3: Collaborate with the Development Team.
#4: Look beyond User Stories.
#5: Proactively Manage your Product Backlog.
#6: Make Product Backlog Visible, Easily Accessible.

45. RELEASE PLAN
It’s a type of project plan covers the next three to six months.

46. PRODUCT ROADMAP
A product plan that looks beyond an individual project or release.

47. ANY RELATION?
derive release plan from the product roadmap (using the product
backlog)

48. BEHAVIOUR DRIVEN
DEVELOPMENT
Getting started with

49. WHY BBD?
A. Zoom in the smallest pieces of behaviours.
B. Narrow communication gaps.
C. Better understanding of the customer needs.
D. Everyone knew what a Story.
E. A common definition of “done”, Pass this Test.
As it speaks the HOW not what.

50. GHERKIN FORMAT
Title (one line describing the story)
Narrative:
As a [role]
I want [feature]
So that [benefit]
Acceptance Criteria: (presented as Scenarios)
Scenario 1: Title
Given [context]
And [some more context]...
When [event]
Then [outcome]
And [another outcome]...

51. ACCEPTANCE TESTING
Define Acceptance Test Process
Identify
Scenarios
Use Examples
and Test Data
Engineering
Consider
Scenarios for
NFRs
Write Scenarios

52. ENGINEERING TEST DATA
GIVEN a Premium of 1500$
And a Discount Percent of 5%
Scenario: Calculate Premium Discount
WHEN customer qualifies for a discount
THEN Discount Amount = 75$
GIVEN Set-up Data
WHEN Execution Data
THEN Evaluation Data