1. Summary: What is a User Story?
A user story is a short, simple description
of a feature or requirement written from the perspective of the person who
desires the functionality - typically a user or customer. In Agile development,
user stories replace traditional system requirements to promote flexibility,
collaboration, and fast iteration.
A user story typically follows the format:
“As a [type of user], I want [an action] so that [a benefit/a value].”
This ensures the feature is grounded in user value. User stories are
intentionally brief and act as placeholders for further conversation and
refinement. They are prioritised in a product backlog, broken down into epics
or tasks, and selected for development during sprint planning.
A well-written user story is INVEST:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
The 'Three Cs' of user stories are:
- Card: The written description (usually on a card or in a tracking system)
- Conversation: Dialogue among stakeholders to clarify and refine
- Confirmation: Acceptance criteria that confirm completion
This method supports iterative development, continuous feedback, and
stakeholder engagement.
2. Glossary of Agile User Story Methodology
· User Story: A brief, simple description of a feature from the user's perspective.
· Agile: A methodology emphasizing iterative development, collaboration, and flexibility.
· Product Backlog: A prioritized list of all desired work or features.
· Epic: A large user story that can be broken down into smaller ones.
· Task: A technical work unit derived from a user story.
· Sprint: A fixed time period for completing selected user stories.
· Sprint Planning: A meeting to choose which user stories to implement during a sprint.
· INVEST: Checklist for good user stories: Independent, Negotiable, Valuable, Estimable, Small, Testable.
· Three Cs: Card (description), Conversation (discussion), Confirmation (acceptance criteria).
· Acceptance Criteria: Conditions that must be met for a story to be complete.
· Customer-Centric: Focus on delivering value to the user, not internal technical needs.
3. Comparison of Agile User Stories vs. SSADM
SSADM (Structured Systems Analysis and
Design Methodology) is a waterfall methodology focused on thorough planning,
rigorous documentation, and structured stages: feasibility, requirements
analysis, logical data modeling, etc. It is best for stable and regulated
environments.
Agile uses evolving user stories instead of static requirements. It values
working software, frequent feedback, and adaptation. Documentation is minimal
and collaboration is central.
Agile’s user stories fit a 'Three Layered' approach to requirements:
1. Epics (high-level goals)
2. Stories (concrete features)
3. Tasks (developer-level implementation units)
In contrast, SSADM follows:
1. Business Requirements
2. Functional Specification
3. Technical Specification
Where SSADM assumes requirements are knowable upfront, Agile embraces change
and iterative clarification.
4. Glossary Mapping: Agile vs. SSADM
|
Agile Term |
SSADM Equivalent |
Comment / Mapping Logic |
|
User Story |
Process Specification |
Describes functionality; refined into DFD and ELH in SSADM |
|
Epic |
Business Area Definition |
High-level domain requirements |
|
Task |
Elementary Process / Module |
Breakdown of a process step in DFD |
|
Product Backlog |
Requirements Catalogue |
Centralised list of required system behaviours |
|
Sprint |
Phase in Project Plan |
Time-boxed execution within structured lifecycle |
|
Acceptance Criteria |
Test Specification |
Formal validation in SSADM |
|
Three Cs |
Structured Interview + Requirement Statement |
Story lifecycle mirrors early SSADM stages |
|
INVEST |
Requirement Quality Guidelines |
SSADM lacks explicit acronym but uses best practice |
|
Card |
Requirement Entry |
Initial placeholder; becomes documented formally in SSADM |
|
Conversation |
Stakeholder Workshops |
Corresponds to structured interviews and JAD sessions |
|
Confirmation |
Verification via Test Plan |
Formalised in SSADM Test and Evaluation phase |
|
Backlog Grooming |
Requirements Review Meeting |
SSADM equivalent is periodic review cycles |
|
Logical Model |
LDM (Logical Data Model) |
Agile infers data; SSADM models explicitly |
|
Flow of Interaction |
DFD (Data Flow Diagram) |
DFDs model data movement—analogous to interaction flow |
|
State or Scenarios |
ELH (Entity Life History) |
Entity behaviour over time; maps loosely to user scenarios |
0 comments:
Post a Comment
Keep it clean, keep it lean