Requirements analysis in agile projects. The “user story” is a particular format:
As a ROLE, I want GOAL so that REASON.
- Fill in the three placeholders (all-caps) – they basically cover the WHO, WHAT, and WHY.
- Some specific examples for a photo management application:
- As an amateur photographer, I want to organize photos into collections so that I can browse easily.
- As a professional photographer, I want to adjust color reproduction and white balance so that I can prepare photos for optimal quality.
- As an amateur photographer, I want to crop pictures to
different dimensions so I can frame the content appropriately or
prepare for print to a particular size.
- Condition: Cropping feature should have selectable aspect ratios, including 4×6, 5×7, 8×10, HD (1920×1080), square (1×1).
- Example: As an instagram user, I want to upload selected photos to instagram so I can become famous.
- Write them on cards (paper or digital)
- More detail can be added either by splitting one story into several, or by adding “acceptance conditions” beneath them, carrying details or criteria.
- Sometimes in documenting requirements/stories, simple words carry
very precise meanings:
- want vs need
- must vs may vs shall vs will
- Group by user role
- Prioritize just by ordering the cards.
- Tracking progress on each story can be done as a “kanban” board.
- Columns in the kanban can represent various stages of completeness.
- Backlog = a pipeline of prioritized stories to be implemented.
- Undertake a “sprint” - a short iteration (2-4 weeks)
- Select some number of stories from the backlog to accomplish during current sprint.
- Two roles provide competing pressure on how much to undertake in a
- “Product owner” will prioritize the stories, wants to get as much done as fast as possible.
- “Project manager” will decide how many for each sprint, and/or max # tasks/stories that can appear in each column of kanban board.
- Also, the analogy of “pigs vs chickens” for those roles that are “committed” vs merely “involved”.