A Guide for Effective Software Development.pptx

1. Understanding User Stories
:
A Guide for Effective Software
Development

2. 2
Contents
Section
1
User Stories
What is a user story
?
Why write user story
?
User story component
Different between user story and tasks
Section
2
Acceptance criteria
What is acceptance criteria
?
Why write acceptance criteria
?
Acceptance critical checklist
Example of acceptance criteria

3. 3
Understanding User Stories: A Guide for Effective Software Development
What is a user story
?
A user story is a simple, concise description of a feature or functionality
from an end user's perspective. It helps development teams
understand user needs, ensuring that the final product meets
expectation
User stories typically follow the format
:
"
As a [user role], I want to [goal] so that [reason]
"

4. 4
Clear Communication
User-Centric Approach
Improves Collaboration
Flexible and Adaptable
Writing user stories is essential for several reasons:
Why Do We Write User Stories
?
Enhances Prioritization

5. 5
How to Write a User Story
• Determine who will use the feature (e.g., Dispatcher,
Paramedic, Controller).
• What does the user want to achieve?
• Why does the user need this functionality?
• Keep it simple, specific, and focused.
• Define acceptance criteria to verify completion.
Clear
Communication
Identify the
User Role
Define
the Goal
Explain
the
Benefit
Enhances
Prioritization

6. 6
Why not just use ‘Tasks’ ?
User Stories Tasks
A user story = the WHAT The task = the HOW
User stories describe a piece of functionality
from the point of view of the user
“What are the activities we need to perform
in order to deliver outcomes(user stories)”
Divided features into business processes Tasks are individual pieces of work

7. 7
User story Checklist
Negative scenario of the functionality
What system/feature intends to do
Functional and non-functional use cases
End-to-user flow
The impact of a user story to other features
UX concerns
User Story should NOT include
User Story should include
Technical details or system implantation
Technical details or system Multiple independe
features in on story (Too broad)
Non –User- Centered Requirements
Deadline or project Timeline

8. 8
Example of user story

9. 9
Components of a User Story
Title
A short, descriptive name for the story
.
Priority
Critical/High/Medium/Low
Precondition
Internet connection
As a :(Type of user)
I want to :(Perform some task)
So that I can :(Achieve some goal)
Acceptance criteria
Given :(Some context)
When :(Some action is
carried out)
Then :(a set of observable
outcomes should)
Description
The standard format: "As a [user], I
want to [goal] so that [reason]
".
Acceptance criteria
Defines conditions that must be met
for the story to be considered
complete
.
Platform
Web/App

10. 10
Example User Story
Title: Assign Ambulance to Incident
Platform: Web/App
Pre-condition: Have validated username and password
Description:
"As a Dispatcher, I want to assign an ambulance to an
incident so that I can ensure timely emergency response."
Acceptance Criteria:
•The system should allow the dispatcher to select an
available ambulance.
•The assigned ambulance should receive an alert with
incident details.
•The system should update the status of the
ambulance.
Notes: This the minimum compound of a user story .writer can add additionally
Business rules, Relationship with other stories, Massages, post condition

11. 11
What is Acceptance criteria
?
What is Acceptance criteria
?
Acceptance criteria or 'conditions of satisfaction' provide a detailed
scope of a user's requirement They help the team to understand the
value of the story and set expectations as to when a team should
consider something done
.
Acceptance Criteria Goals :
• To clarify what the team should build before they start work
• To ensure everyone has a common understanding of the problem
• To help the team members know when the story is complete
• To help verify the story via automated tests

12. 12
Acceptance Criteria Checklist
Keep them short
Write from the perspective of user
Keep them simple
Make the value/benefit of the story clear-
what is the reason for the story
Write stories as a team and have validation
stage after writing
User acceptance criteria to show a MVP
Acceptance Criteria should NOT include
Acceptance Criteria should include
Code review was done
Performance testing performed
Non-blocker or major issues
Acceptance and functional testing done
Why?
Acceptance criteria should not include any of the above, because the team
should already have clear understanding of what the Definition of Done (DoD)
means.
Describe one piece of functionality. If you
have to write and break it into 2 stories

13. 13
Tools Used in Software Development

14. Thank You
Don’t
split a story on waterfall
-
like phases
Unless you like riding very, very large waves of
failure