Work Item Creation

Overview: Creating well-structured work items is fundamental to successful project delivery in Safedevops. This guide covers the creation process, best practices, and templates for all work item types in the SAFe framework.

Work Item Hierarchy

Safedevops follows the SAFe work item hierarchy, where each level serves a specific purpose in planning and execution:

Work Item Type Purpose Typical Duration Created By
Epic Large business initiatives that span multiple PIs 3-12 months Epic Owner, Product Manager
Feature Functionality that delivers customer value within a PI 1-3 months Product Manager
User Story Small, deliverable pieces of functionality 1-2 weeks Product Owner
Task Technical implementation work for stories 1-16 hours Development Team

General Creation Process

Step-by-Step Creation Workflow

Step 1: Access Work Item Creation
  • Navigate to the appropriate backlog (Epic, Program, Team)
  • Click the "Create New" or "+" button
  • Select the work item type to create
Step 2: Complete Required Fields
  • Enter a clear, descriptive title
  • Provide detailed description
  • Set appropriate priority and business value
  • Assign ownership and team relationships
Step 3: Define Acceptance Criteria
  • Specify what "done" means for this work item
  • Include functional and non-functional requirements
  • Add test scenarios and validation criteria
Step 4: Review and Save
  • Review all entered information for completeness
  • Save the work item to the backlog
  • Add to appropriate planning increments if ready

Epic Creation

Epic Creation Fields

Field Required Description Example
Title Required Concise epic name "Customer Self-Service Portal"
Description Required Detailed business case and goals Full business context and objectives
Business Value Required Priority and value justification High - $2M revenue opportunity
Epic Owner Required Person responsible for epic delivery John Smith, Product Manager
Success Metrics Optional Measurable success criteria 50% reduction in support tickets

Epic Template

Epic Title: [Concise Epic Name] Business Case: - Problem Statement: [What problem are we solving?] - Market Opportunity: [What's the business opportunity?] - Target Outcomes: [What specific outcomes do we expect?] Success Criteria: - [Measurable criterion 1] - [Measurable criterion 2] - [Measurable criterion 3] Assumptions: - [Key assumption 1] - [Key assumption 2] Risks: - [Risk 1 and mitigation approach] - [Risk 2 and mitigation approach]

Feature Creation

Feature Creation Best Practices

  • Right-sized Scope: Features should be deliverable within a single Program Increment
  • Customer Focus: Describe features from the customer's perspective
  • Clear Benefit: Articulate the specific benefit to users
  • Testable: Define how the feature will be validated

Feature Creation Fields

Field Required Description
Title Required Clear feature name that describes capability
Parent Epic Required Epic this feature contributes to
Benefit Hypothesis Required Expected business benefit and user value
Acceptance Criteria Required Specific, testable criteria for completion
Priority Required Relative importance within the epic

Feature Template (Benefit Hypothesis Format)

Feature: [Feature Name] Benefit Hypothesis: We believe that [building this feature/capability] For [target users/customers] Will result in [expected business outcome] We will know we have succeeded when we see [measurable signal] Acceptance Criteria: - [Functional criterion 1] - [Functional criterion 2] - [Non-functional criterion 1] - [Non-functional criterion 2] Definition of Done: - [ ] Code complete and reviewed - [ ] Tests written and passing - [ ] Documentation updated - [ ] Stakeholder acceptance obtained

User Story Creation

User Story Format

User stories follow the standard format to ensure clarity and focus on user value:

Standard User Story Format:
"As a [type of user], I want [goal/desire] so that [benefit/value]"

User Story Creation Fields

Field Required Description
Title Required Brief story description
User Story Required Standard format: As a... I want... So that...
Parent Feature Required Feature this story contributes to
Acceptance Criteria Required Specific conditions for story completion
Story Points Optional Relative size estimate
Priority Required Relative importance within feature

User Story INVEST Criteria

Ensure stories meet INVEST criteria:
  • Independent: Can be developed independently
  • Negotiable: Details can be refined through discussion
  • Valuable: Delivers value to users or business
  • Estimable: Team can estimate the effort required
  • Small: Can be completed within a single iteration
  • Testable: Can be verified through testing

Task Creation

Task Breakdown Guidelines

  • Granular Work: Tasks should be 1-16 hours of work
  • Skill-Specific: Consider different skills needed (dev, test, design)
  • Dependencies: Identify task-level dependencies
  • Acceptance: Clear criteria for task completion

Common Task Categories

Category Examples Typical Size
Development Implement API, Create UI component, Database changes 4-8 hours
Testing Write unit tests, Integration testing, Manual testing 2-6 hours
Design UI mockups, System design, Architecture review 2-8 hours
Documentation API docs, User guides, Technical specifications 1-4 hours

Task Template

Task: [Specific Task Description] Parent Story: [User Story Title] Description: [Detailed description of the work to be done] Acceptance Criteria: - [Criterion 1] - [Criterion 2] Estimated Hours: [1-16 hours] Dependencies: - [Dependency 1] - [Dependency 2] Notes: [Any additional context or considerations]

Work Item Relationships

Hierarchical Relationships

  • Epic → Features: Features that contribute to epic goals
  • Feature → User Stories: Stories that implement feature functionality
  • User Story → Tasks: Technical tasks needed to complete the story

Dependency Relationships

  • Predecessor/Successor: Work items that must be completed in sequence
  • Blocking/Blocked: Work items that prevent others from starting
  • Related: Work items that are connected but not dependent
Pro Tip: Establish relationships during creation to maintain traceability and enable better planning and tracking.

Quality Guidelines

Definition of Ready Checklist

Before moving work items to active development:
  • ✓ Clear, understandable description
  • ✓ Well-defined acceptance criteria
  • ✓ Appropriate size for the work item type
  • ✓ Dependencies identified and managed
  • ✓ Business value clearly articulated
  • ✓ Assigned to appropriate team/individual
  • ✓ Priority established within parent work item

Common Creation Mistakes

Avoid These Common Pitfalls:
  • Vague Descriptions: Insufficient detail for development teams
  • Missing Acceptance Criteria: No clear definition of completion
  • Wrong Size: Work items too large or too small for their type
  • Technical Focus: Describing implementation instead of business value
  • Unclear Ownership: No clear responsibility assignment

Collaboration in Creation

Stakeholder Involvement

Work Item Type Primary Creator Key Collaborators Review Process
Epic Epic Owner Business Stakeholders, Architects Epic Review Board
Feature Product Manager Development Teams, System Architect PI Planning Review
User Story Product Owner Development Team, UX Designer Backlog Refinement
Task Development Team Team Members, Scrum Master Sprint Planning

Refinement Process

  • Initial Creation: Basic structure and key details
  • Collaborative Refinement: Team input and clarification
  • Acceptance Criteria Definition: Detailed completion criteria
  • Estimation: Size and effort estimation
  • Final Review: Readiness confirmation before commitment
SAFe® and Scaled Agile Framework® are registered trademarks of Scaled Agile, Inc.