This document outlines the role and responsibilities of a Business Analyst (BA) in project teams, emphasizing the importance of user stories in documenting requirements. It highlights key skills required to be an effective BA and emphasizes the structure, acceptance criteria, and common mistakes in user story writing. Overall, it serves as a guideline for developing clear and valuable requirements in software development projects.

1. User Stories: be simple, be useful
Презентація менторів Masters Academy
Master of Code Ukraine

2. Follow us:
освітній проект Masters Academy
Fb cherkasy.masters
компанія Master of Code Global
Fb master.of.code.ukraine
Insta master.of.code.ukraine
#MAradnik
#mocglobal

3. Business Analyst:
Role in Project and
Team

4. BA GOAL:
● Investigate Problem
● Find Solution
● Develop Concept

5. Business Analysis Process Flow
● Identify customer needs
● Develop solution concept
● Design requirements for future product
● Document requirements in the form of specification
● Consult Developers and QA Engineers through the
whole SDLC
5

6. BA Responsibilities
● Assistance with customer’s
business case
● Requirements gathering strategy
development
● Planning and monitoring
● Key stakeholders and user classes
determination
● Requirements gathering
● Requirements documenting
● Requirements translating and
simplifying
● Requirements verification
● Requirements
prioritization
● Requirements management
and communication
6

7. BA’s Working Day
● Meetings with project team and customer
● Development of solution concept
● Work with analysis tools
● Work with requirements
● Assistance to developers and testers
● Learning advanced strategies for gathering,
reviewing and analyzing requirements
7

8. What it Takes to be a BA
● Analytical thinker
● Ability to quickly adapt in a ‘new’ area
● Critical thinker
● Decision-maker
● Fast learner
● Excellent communicator
● Attentive to details
● Facilitation skills
8

9. User Story
An informal, natural language description of one or more features of a software
system
Epic
A large user story that cannot be delivered as defined within a single iteration or
is large enough that it can be split into smaller user stories

10. Epic
As a Frequent Visitor, I want to make food orders customized to my
preference, so I save time.
Related User Stories
As a Frequent Visitor, I want to pay for my food using bonuses so that I can
save money
As a Frequent Visitor, I want to easily order my favourite meals so that I
can save time
As a Premium Visitor, I want to request a program upgrade so I can get
more bonuses

11. What is special about User Stories?
● Not a detailed requirement
● Negotiable intention
● Short
● Easy-to-read
● Easy-to-understand
● Easy-to-estimate
● Brings value to product
● Easy-to-manage list
● Details can be added on the fly
11

12. US Structure
As a <Role/User>,
I want <some goal>,
so that <some reason>
12

13. Actor
Action
Value / Impact1 13

14. 1 Actor
As a User, I should be able to log my working hours so that
I get paid.
As an Assignee, I want to be able to log my working hours
so that I get paid.
14

15. 1 Action
As an Assignee, I want to see a dropdown so I can select a
task to log time against.
As an Assignee, I want to be able to select between tasks
assigned to me so that I can log time against the task I
worked today.
15

16. 1 Value / Impact
As a Shopper, I want to pay with a credit card, so that I can
purchase the selected goods.
As a Shopper, I want to pay with a credit card.
16

17. Independent
Negotiable
Valuable
Estimable
Small
Testable
17

18. As a Conference Attendee, I want to be able to register
online, so I can register quickly and cut down on paperwork
● A user cannot submit a form without completing
all the mandatory fields.
● Information from the form is stored in the
registrations database.
● Protection against spam is working.
● Users can pay by credit card.
● An acknowledgment email is sent to the user
after submitting the form.
Acceptance Criteria
18

19. Typical Mistakes in US Writing

20. Ignoring User's role
As a User, I want to be able to manage
advertisements, so I can delete old ones as well
as the ads added by mistake
20

21. No value for business user
As a User, I want to be able to manage
advertisements, so I can delete old ones as well
as the ads added by mistake
21

22. Too formal / too detailed User Stories
As a User, I want to be able to manage advertisements
from a sidebar on my landing page, so I can delete old
ones as well as the ads added by mistake.
As an Ads Portal Admin, I want to be able to manage
advertisements, so I can keep the ads list up to date.
22

23. Presenting a technical task as a User Story
As a Meeting Organizer, I should be able to see a date
picker on my web form, so I can set up date.
As a Meeting Organiser, I should be able to set up meeting
start date, so I don't forget when my meeting begins.
23

24. No Acceptance Criteria
Avoiding discussion

25. Key Points in User Story Writing:
● Multiple small User Stories are always better than one large User Story
● User Story is aimed to be clear for the business - no technical slang
● User Story should be easily verifiable
● User Story should have Acceptance Criteria
● Acceptance Criteria for a User Story should be defined prior to development start
● User Story should lead to a logical end, i.e. express a result of an action
● User stories should explain WHAT should be done, not HOW
● User Story should be small enough to fit into an iteration

26. Useful Links:
User Story mapping with Jeff Patton
User Stories by Mike Cohn
Videos on User Story Writing
Acceptance Criteria Writing Guide
Developing Effective Agile Requirements
12 Must-Read blogs for BA
IT Network - Business Analysis & Project
Management