Elixion

Issue Types

Understanding the different issue types in Elixion - Stories, Bugs, Tasks, and Epics

Issue Types

Elixion supports multiple issue types to help you categorize and track different kinds of work. Each type has its own purpose, fields, and best practices.

Available Issue Types

| Type | Icon | Purpose | |------|------|---------| | Epic | 🎯 | Large feature spanning multiple sprints | | Story | 📖 | User-facing functionality | | Task | ✓ | Technical or administrative work | | Bug | 🐛 | Defect or issue | | Tech Debt | 🔧 | Technical improvements | | Spike | 🔍 | Research and investigation |

Epic

Epics are large bodies of work that can be broken down into smaller stories and tasks. They typically span multiple sprints and represent significant features or initiatives.

When to Use

  • Major features requiring multiple stories
  • Quarterly or release-level goals
  • Cross-team initiatives
  • Product roadmap items

Epic Structure

Epic: User Authentication System
├── Story: Implement login page
├── Story: Add password reset
├── Story: Enable social login
├── Task: Set up authentication database
└── Bug: Fix session timeout issue

Epic Fields

| Field | Description | |-------|-------------| | Start Date | When work begins | | Target Date | Expected completion | | Progress | % complete (auto-calculated) | | Child Issues | Linked stories/tasks | | Business Value | Relative importance |

Progress Tracking

Epic progress is calculated from child issues:

Progress = (Done Issues / Total Issues) × 100%

Example:
- 10 total child issues
- 6 marked as Done
- Progress: 60%

Best Practices

✓ Do:

  • Write clear business objectives
  • Set realistic target dates
  • Break down into manageable stories
  • Track dependencies between epics

✗ Don't:

  • Create epics that are too large
  • Use epics for single features
  • Leave epics without children
  • Forget to close when complete

Story

Stories represent user-facing functionality written from the user's perspective. They follow the user story format and deliver clear value.

User Story Format

As a [type of user],
I want [goal/feature],
so that [benefit/reason].

Examples

Good Stories:

As a registered user,
I want to reset my password via email,
so that I can regain access if I forget it.

As a team lead,
I want to see sprint velocity trends,
so that I can plan future sprints accurately.

Story Fields

| Field | Description | |-------|-------------| | Story Points | Effort estimate | | Acceptance Criteria | Definition of done | | Sprint | Sprint assignment | | Epic | Parent epic link |

Acceptance Criteria

Write testable criteria:

## Acceptance Criteria

### Scenario: Successful password reset
- Given I am on the login page
- When I click "Forgot Password"
- And I enter my registered email
- Then I should receive a reset link within 5 minutes

### Scenario: Invalid email
- Given I enter an unregistered email
- Then I should see "Email not found" error

Story Splitting

Large stories should be split:

| Original | Split Into | |----------|------------| | User profile page | View profile | | | Edit profile | | | Upload avatar | | | Change password |

Best Practices

✓ Do:

  • Focus on user value
  • Keep stories sprint-sized (< 8 points)
  • Include acceptance criteria
  • Write from user perspective

✗ Don't:

  • Include technical jargon
  • Combine multiple features
  • Skip acceptance criteria
  • Make stories too vague

Task

Tasks are specific, actionable work items that may not deliver direct user value but are necessary for the project.

When to Use

  • Technical setup work
  • Documentation
  • Code refactoring
  • Administrative tasks
  • Subtasks of stories

Task Examples

✓ Set up CI/CD pipeline
✓ Update README documentation
✓ Configure SSL certificates
✓ Migrate database schema
✓ Review pull request

Task Fields

| Field | Description | |-------|-------------| | Time Estimate | Hours expected | | Time Logged | Hours spent | | Parent Issue | Story or epic link |

Subtasks

Tasks can be subtasks of stories:

Story: Implement login page
├── Task: Create login form component
├── Task: Add form validation
├── Task: Implement API integration
├── Task: Write unit tests
└── Task: Add accessibility attributes

Best Practices

✓ Do:

  • Be specific and actionable
  • Include clear deliverables
  • Link to parent stories
  • Track time if needed

✗ Don't:

  • Make tasks too large
  • Use vague descriptions
  • Leave orphaned tasks

Bug

Bugs represent defects in existing functionality that need to be fixed.

Bug Report Structure

## Summary
Brief description of the bug.

## Environment
- Browser: Chrome 120.0
- OS: macOS Sonoma
- Device: MacBook Pro M3
- Version: 2.3.1

## Steps to Reproduce
1. Navigate to /settings
2. Click "Save" button
3. Observe error

## Expected Behavior
Settings should save successfully.

## Actual Behavior
Error message appears: "Failed to save"

## Severity
Major - Core functionality broken

## Additional Info
[Screenshot]
[Console logs]

Bug Fields

| Field | Description | |-------|-------------| | Severity | Critical, Major, Minor, Trivial | | Affected Version | Where bug appears | | Fixed Version | Where fix is released | | Environment | Browser, OS, device | | Regression | Was this working before? |

Severity Levels

| Severity | Description | Example | |----------|-------------|---------| | Critical | System unusable | Cannot log in | | Major | Core feature broken | Payment fails | | Minor | Feature impaired | Slow load time | | Trivial | Cosmetic issue | Typo in label |

Bug Workflow

New → Triaged → In Progress → Fixed → Verified → Closed
                    ↓                     ↓
               Cannot Reproduce      Reopened

Best Practices

✓ Do:

  • Provide reproduction steps
  • Include screenshots/logs
  • Set appropriate severity
  • Test the fix

✗ Don't:

  • Report duplicates
  • Skip environment info
  • Exaggerate severity
  • Close without verifying

Tech Debt

Tech debt represents technical work needed to improve code quality, performance, or maintainability.

Categories

| Category | Examples | |----------|----------| | Code Quality | Refactoring, removing duplication | | Testing | Adding tests, improving coverage | | Performance | Optimization, caching | | Security | Vulnerability fixes, updates | | Infrastructure | Upgrades, migrations |

Tech Debt Template

## Current State
What is the current situation?

## Problems
- Performance impact
- Maintenance burden
- Security risk

## Proposed Solution
How to address this?

## Benefits
- Improved performance
- Easier maintenance
- Reduced risk

## Effort
Estimated time/points

## Dependencies
What needs to happen first?

Best Practices

  • Document why it matters
  • Track business impact
  • Prioritize with features
  • Schedule regularly

Spike

Spikes are time-boxed research tasks to reduce uncertainty before committing to implementation.

When to Use

  • New technology evaluation
  • Architecture decisions
  • Unknown requirements
  • Estimating complex features

Spike Template

## Research Question
What are we trying to learn?

## Time Box
Maximum: 2 days (16 hours)

## Background
Why do we need this information?

## Approach
- Review documentation
- Build proof of concept
- Test performance

## Output
- [ ] Decision document
- [ ] Recommendation
- [ ] Estimated effort for implementation

Spike Outcomes

After completion, create:

  1. Findings document
  2. Follow-up stories/tasks
  3. Architecture decision record (if applicable)

Next: Issue Templates - Create reusable issue templates