SpiraTeam Agile Test Management: Sprints, Stories, and Testing in One Platform

Many QA teams face a coordination problem: the development team uses Jira for sprints and stories while QA uses a separate test management tool. Requirements get duplicated, test coverage is invisible to developers, and sprint ceremonies lack quality context.

SpiraTeam addresses this by combining project management and test management in one platform. This guide covers how SpiraTeam supports agile workflows from sprint planning through testing and release.

SpiraTest vs SpiraTeam

SpiraTest is the testing-only product. SpiraTeam adds:

• Iterations/Sprints — time-boxed work periods with capacity planning
• Tasks — developer-level work items linked to requirements
• Planning Board — visual sprint board (Kanban/Scrum style)
• Velocity Tracking — story points and sprint velocity charts
• Source Code Integration — commits linked to tasks and requirements

SpiraTest handles requirements, test cases, and defects. SpiraTeam handles those plus the full development workflow. If your team needs to track development work and testing in one place without Jira, SpiraTeam is designed for that.

Setting Up Agile Structure in SpiraTeam

Create a Product

A product in SpiraTeam maps to a software product or project. Configure it with:

• Template (defines workflows, custom fields)
• Description and start date
• Initial release/version structure

Configure Releases and Sprints

SpiraTeam uses a two-level hierarchy:

• Releases — major versions (v1.0, v2.0, Q3 Release)
• Iterations/Sprints — time-boxed periods within a release (Sprint 1, Sprint 2)

Create the release structure:

1. Navigate to Planning → Releases
2. Click Insert Release for the main release version
3. Under each release, click Insert Sprint to add iterations
4. Set sprint start date, end date, and capacity (story points or hours)

Capture Team Capacity

For each sprint, configure team capacity:

1. Open the sprint
2. Click the People tab
3. Add team members and their availability for this sprint (days available × hours/day)

Capacity appears in the planning board to help balance work across team members.

User Stories and Requirements

SpiraTeam treats user stories as requirements with additional agile fields.

Creating User Stories

1. Navigate to Requirements
2. Click Insert → Insert User Story
3. Fill in:
   • Name — "As a user, I can reset my password via email"
   • Description — acceptance criteria
   • Story Points — estimated effort
   • Sprint — assign to the target sprint
   • Owner — responsible developer
   • Priority — Critical, High, Medium, Low

Organizing Stories in Epics

Group related stories under epics using the hierarchy:

Epic: User Authentication
├── Story: Register with email
├── Story: Login with email/password  
├── Story: OAuth login (Google, GitHub)
└── Story: Password reset flow

The planning board shows epics and their child stories with sprint assignment and completion status.

Sprint Planning

The Planning Board

The SpiraTeam planning board (similar to a physical sprint board) shows user stories as cards organized by sprint. Navigate to Planning → Planning Board.

In planning sessions:

• Drag unassigned stories from the product backlog into the sprint
• Stories show point estimates against sprint capacity
• Over-capacity sprints are highlighted

Backlog Grooming

Manage the product backlog in Planning → Product Backlog. Sort by priority, assign story points, and move stories to upcoming sprints.

For each sprint planning session:

1. Open the Planning Board
2. Review unassigned stories in "Backlog" column
3. Drag high-priority stories into the sprint column
4. Monitor sprint capacity remaining

Task Breakdown

Under each user story, developers create tasks:

1. Open a user story
2. Click Tasks tab
3. Click Add Task
4. Set task name, owner, estimated hours, and type (development, code review, deployment, etc.)

Tasks represent the actual work done; stories represent the feature. This separation lets you track developer progress on tasks while testers track quality against stories.

Linking Tests to Stories

This is where SpiraTeam provides traceability that Jira + separate test management can't match natively.

From Stories to Test Cases

1. Open a user story
2. Click the Test Cases tab
3. Click Add Association
4. Select test cases that verify this story

Now the story shows test coverage: "3 of 4 linked test cases passing."

Creating Tests from Stories

For each user story, create test cases that verify the acceptance criteria:

1. Open the story
2. Navigate to Test Cases tab
3. Click Create Test Case from Requirement
4. SpiraTeam pre-fills the test case name from the story name

This ensures every story gets a test case — preventing the "we forgot to write tests for that story" problem.

Test Execution During Sprints

Creating a Sprint Test Set

At the start of each sprint, create a test set for sprint testing:

1. Test Sets → Insert Test Set
2. Name: "Sprint 24 Testing"
3. Assign to Sprint 24
4. Add test cases for all stories in Sprint 24

As development completes stories, testers execute the linked test cases against the test set.

Tracking Sprint Testing Progress

The sprint dashboard shows:

• Stories: total, in progress, done
• Tasks: total, in progress, done
• Test Cases: total, executed, passed, failed

When a story's test cases all pass, the story is ready for acceptance. When test cases fail, linked defects appear on the story's card — giving developers immediate context.

Defects Within Sprints

Defects (incidents) logged during sprint testing are linked to:

• The test case that found them
• The user story the test case covers
• The sprint where they were found

The sprint board shows defect counts per story. Before closing a sprint, review defects: unresolved critical defects block sprint acceptance.

Velocity and Metrics

SpiraTeam tracks velocity (story points completed per sprint) automatically.

Viewing the Velocity Chart

Navigate to Reports → Sprint/Iteration Velocity Chart. The chart shows:

• Planned points per sprint (committed)
• Completed points per sprint (delivered)
• Rolling average velocity

Use velocity for sprint planning: if average velocity is 40 points, committing to 60 points in a sprint is unrealistic.

Burndown Charts

The sprint burndown chart shows remaining work (story points or hours) over the sprint timeline:

1. Navigate to the active sprint
2. Click Burndown Chart
3. View remaining work vs. ideal burn rate

A sprint that's burning down faster than ideal is on track. One that's flat or increasing is in trouble — useful for mid-sprint corrections.

Test Coverage by Sprint

For each sprint, the coverage report shows:

• Stories with full test coverage
• Stories with partial test coverage
• Stories with no test cases

This becomes a sprint done-definition criterion: a story isn't done until it has passing test cases.

CI/CD Integration for Automated Tests

SpiraTeam integrates with CI/CD to bring automated test results into sprint context.

When CI runs automated tests:

1. Test results report to SpiraTeam via API or Jenkins plugin
2. Test cases in SpiraTeam are marked passed/failed
3. User stories linked to those test cases update coverage status
4. Sprint dashboard reflects automated test results alongside manual results

Configure this via Administration → Automation Engines and the CI/CD plugin setup (see the SpiraTest CI/CD integration guide for details).

Working With Remote and Distributed Teams

SpiraTeam's web-based interface supports distributed teams without additional tooling.

Time Zone Support: Sprint dates and activity timestamps respect user time zones.

Activity Feed: Each product has an activity stream showing recent changes — stories updated, defects logged, test cases executed — keeping distributed team members in sync.

Email Notifications: Configure notifications per event type and per team member. Developers get notified when defects are assigned; QA gets notified when stories move to "ready for testing."

@Mentions: Tag team members in comments on stories, defects, and test cases. Tagged users receive notifications.

SpiraTeam vs Jira + TestRail

The key question teams ask: "Should we use SpiraTeam, or combine Jira with TestRail?"

Choose SpiraTeam if you want single-system simplicity, don't need the Jira ecosystem, or have on-premises requirements.

Choose Jira + TestRail if your team is already in Jira, you need Jira's agile UX, or you rely on the Jira app marketplace.

Getting Maximum Value from SpiraTeam

Best practices for agile teams:

1. Create test cases as stories are created — not after. This enforces quality from the start.
2. Define "done" to include passing tests — a story isn't done without passing test cases.
3. Use the sprint dashboard during standup — show test pass rates alongside velocity.
4. Link all defects to the story they affect — gives developers and QA shared context.
5. Run automated CI tests mapped to SpiraTeam stories — automated coverage contributes to story done-status.
6. Review coverage report before sprint demos — catch uncovered stories before demo day.

Continuous Monitoring Beyond Sprint Testing

SpiraTeam covers what you test during development. For knowing whether your production app is working between releases, HelpMeTest runs continuous tests 24/7 — alerting you the moment a user flow breaks in production.

Write tests in plain English. No test framework required. Monitor production continuously.

Start free →