Managing User Stories in SAFe
User Stories are small, discrete pieces of functionality written from an end-user perspective. They represent the smallest unit of work that delivers value to users and are typically completed within a single iteration. This guide shows you how to create and manage User Stories in Safedevops.app.
User Story Management Overview
User Stories bridge the gap between Features and implementation work. They break down Feature requirements into manageable, testable pieces that development teams can complete in short iterations.
What is a User Story?
In the Scaled Agile Framework (SAFe), a User Story is a short, simple description of a feature told from the perspective of the person who desires the new capability. User Stories are:
- User-Centric: Written from the end user's perspective with clear value proposition
- Iteration-Sized: Small enough to be completed within a single iteration (1-2 weeks)
- Testable: Include clear acceptance criteria that can be verified
- Independent: Can be developed and delivered independently of other stories
- Valuable: Deliver measurable value to the end user
- Estimable: Development teams can estimate the effort required
User Story Example
Here's what a typical User Story looks like in the system, showing the standard format and key information:
Notice how this User Story includes all the essential elements: a clear title following the "As a...I want...so that..." format, detailed description, status tracking, team assignment, and other key metadata.
Creating a New User Story
1. Navigate to Work Items
From the main navigation sidebar, click on "Work Items" to access the work item management area.
2. Create User Story
Click the "Create Work Item" button and select "User Story" from the work item type dropdown, or use the "Quick Create User Story" button if available.
3. Select Parent Feature
User Stories must be associated with a Feature. Use the parent search field to find and select the appropriate Feature that this User Story will implement part of.
4. Basic Information
Complete the essential details for your User Story:
- Title: Use the standard format: "As a [user type], I want [functionality] so that [benefit]"
- Description: Detailed explanation of the user need and expected behavior
- Priority: Set the business priority (High, Medium, Low)
- Status: Initial status (typically "Proposed" or "New")
5. Team Assignment and Ownership
Assign the User Story to the development team:
- Owner: The person responsible for the story (often a Product Owner or Developer)
- Team: The Agile team that will implement the story (required for User Stories)
- Iteration: The specific iteration/sprint when this story will be developed
Note: User Stories are typically planned and executed within team iterations. You can assign a story to an iteration during creation/editing, or use the "Add workitems" dialog from the iteration view to assign existing stories to specific iterations.
User Story Format and Structure
Standard User Story Template
Use the following template for writing effective User Stories:
"As a [user role], I want [functionality] so that [business value]."
Examples:
- "As a registered user, I want to reset my password so that I can regain access to my account."
- "As a product manager, I want to view analytics dashboard so that I can track feature usage."
- "As a customer, I want to save items to wishlist so that I can purchase them later."
User Story Components
Essential Elements:
- User Persona: Clearly identify who will benefit from this functionality
- Functionality: What specific capability or feature is being requested
- Business Value: Why this functionality matters to the user
- Acceptance Criteria: Specific conditions that must be met for the story to be complete
Acceptance Criteria for User Stories
Acceptance criteria define the specific conditions that must be met for a User Story to be considered complete and ready for delivery.
Writing Effective Acceptance Criteria
Given-When-Then Format:
Given [initial context or state]
When [action is performed]
Then [expected outcome]
Example for Password Reset Story:
- Given I am on the login page and have forgotten my password
When I click "Forgot Password" and enter my email address
Then I should receive a password reset email within 5 minutes - Given I have received a password reset email
When I click the reset link and enter a new password
Then I should be able to log in with the new password - Given I attempt to use an expired reset link
When I click the link
Then I should see an error message indicating the link has expired
Acceptance Criteria Best Practices
- Be Specific: Avoid ambiguous terms like "user-friendly" or "fast"
- Include Edge Cases: Consider error conditions and boundary cases
- Make Testable: Each criterion should be objectively verifiable
- Cover All Scenarios: Include both positive and negative test cases
- Define Done: Clearly state what constitutes completion
Story Points and Estimation
Understanding Story Points
Story Points are a relative estimation technique used to size User Stories based on complexity, effort, and uncertainty:
- Relative Sizing: Compare stories to each other rather than absolute time estimates
- Team-Based: Each team develops their own baseline for story point values
- Planning Tool: Used for sprint planning and velocity calculations
- Fibonacci Scale: Common scale: 1, 2, 3, 5, 8, 13, 21
Story Point Guidelines
- 1-2 Points: Simple changes, well-understood work
- 3-5 Points: Moderate complexity, some unknowns
- 8-13 Points: Complex work, significant unknowns (consider breaking down)
- 21+ Points: Too large for a single iteration (must be broken down)
User Story Lifecycle Management
Status Progression
User Stories typically progress through these statuses:
- Proposed: Initial story idea identified
- Ready: Story is refined and ready for development
- In Progress: Development work has started
- Code Review: Implementation complete, under review
- Testing: Story is being tested and validated
- Done: Story meets all acceptance criteria and is complete
- Accepted: Product Owner has accepted the completed story
Integration with Iterations
User Stories are planned and executed within team iterations (sprints):
- Sprint Planning: Stories are selected and committed to for the iteration
- Daily Standups: Progress on stories is discussed daily
- Sprint Review: Completed stories are demonstrated to stakeholders
- Sprint Retrospective: Team reflects on story delivery and process
Assigning Stories to Iterations:
- During Creation/Edit: Select the iteration in the "Iteration" field when creating or editing a User Story
- From Iteration View: Use the "Add workitems" dialog from the iteration management page to assign existing stories
- Bulk Assignment: Select multiple stories and assign them to an iteration simultaneously
- Sprint Planning Sessions: Collaboratively assign stories during team planning meetings
Visual Guide: Adding Work Items to an Iteration
Here's a step-by-step visual guide showing how to add User Stories and Tasks to an iteration using the "Add workitems" dialog:
Step 1: Access Add Work Items
From the iteration management view, click on "Add Work Items" to open the work item assignment dialog.
Step 2: Add to Iteration
Select the User Stories and Tasks you want to add to the iteration, then click "Add to Iteration" to assign them. Only work items belonging to the same team as the iteration will be available for selection.
Important Notes:
- Team Alignment: Only User Stories and Tasks belonging to the same team as the iteration can be added
- Work Item Types: Only User Stories and Tasks can be assigned to iterations (not Epics or Features)
- Status Filtering: Work items already assigned to other iterations will be disabled in the selection dialog
- Bulk Operations: You can select multiple work items and assign them all at once
Creating Child Tasks
User Stories are often decomposed into technical Tasks for implementation:
Breaking Down User Stories
From the User Story details page, you can create Tasks that represent the technical work needed to implement the story. Each Task should be specific, assignable work.
Task Categories:
- Development Tasks: Backend API development, frontend implementation
- Testing Tasks: Unit tests, integration tests, user acceptance testing
- Infrastructure Tasks: Database changes, deployment configuration
- Documentation Tasks: API documentation, user guides
User Story Quality Checklist
INVEST Criteria
Ensure your User Stories meet the INVEST criteria:
- Independent: Can be developed and delivered independently
- Negotiable: Details can be discussed and refined with the team
- Valuable: Delivers clear value to the end user
- Estimable: Team can estimate the effort required
- Small: Can be completed within a single iteration
- Testable: Has clear acceptance criteria that can be verified
Definition of Ready
Before a User Story enters an iteration, ensure it meets the Definition of Ready:
- Clear Acceptance Criteria: All success conditions are defined
- Sized Appropriately: Story points estimated and agreed upon
- Dependencies Identified: Any blocking dependencies are known
- Testable: QA understands how to verify the story
- Technical Feasibility: Development team understands the implementation
Definition of Done
A User Story is considered "Done" when:
- All Acceptance Criteria Met: Every criterion has been verified
- Code Complete: All development work finished and reviewed
- Tests Passing: Unit, integration, and acceptance tests pass
- Documentation Updated: Relevant documentation reflects changes
- Demo Ready: Story can be demonstrated to stakeholders
Collaboration and Communication
Stakeholder Involvement
- Product Owner: Defines business value and acceptance criteria
- Development Team: Estimates effort and implements the story
- Scrum Master: Facilitates planning and removes impediments
- End Users: Provide feedback during reviews and validation
Story Refinement Process
- Backlog Grooming: Regular refinement sessions to improve story quality
- Three Amigos: Collaboration between Product Owner, Developer, and Tester
- Acceptance Criteria Review: Ensure criteria are clear and testable
- Estimation Sessions: Team estimates using planning poker or similar techniques
Metrics and Tracking
User Story Metrics
- Velocity: Average story points completed per iteration
- Cycle Time: Time from story start to completion
- Lead Time: Time from story creation to delivery
- Defect Rate: Number of bugs found in completed stories
- Story Completion Rate: Percentage of committed stories completed per iteration
Continuous Improvement
- Retrospective Insights: Use story data to improve team processes
- Estimation Accuracy: Track and improve estimation skills over time
- Quality Trends: Monitor defect rates and adjust practices
- Flow Optimization: Identify and remove bottlenecks in story delivery
Best Practices
Writing User Stories
- Focus on Value: Always articulate the user benefit
- Keep It Simple: One story should address one user need
- Use Plain Language: Avoid technical jargon in story descriptions
- Include Personas: Be specific about which user type will benefit
Story Management
- Regular Refinement: Continuously improve story quality through grooming
- Vertical Slicing: Stories should deliver end-to-end functionality
- Prioritization: Work on highest value stories first
- Feedback Loops: Gather user feedback early and often
What's Next?
With your User Story created and properly configured, you can now:
- Create Tasks: Break down the story into implementable tasks.
→ Managing Tasks - Plan Iterations: Include the story in sprint planning activities.
→ Managing Iterations - Track Progress: Monitor story progress through development.
→ Work Item Tracking - Manage Dependencies: Identify and track story dependencies.
→ Managing Dependencies