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]"
"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