Scrum Template sample project: Item types
Helix ALM supports the following item types: requirement documents, requirements, test cases, manual test runs, and issues. You can rename and modify these item types to support almost any type of work item or asset your team manages during the development process.
In the Scrum Template project, the team is using Helix ALM to manage epics, user stories, tasks, test cases, manual test runs, and defects.
Note: The following information explains the most commonly used fields in the Scrum Template. Items may contain additional fields.
Epics represent large product features or capabilities that need to be refined based on user needs and broken into manageable chunks for the team to work on. In the Scrum Template, epics are containers for user stories and tasks.
The default Requirement Document item type was renamed to Epic in the Scrum Template.
User stories represent individual features or functions that define what an end user needs to perform their job. User stories contain the following fields.
| Field | Use to: |
|---|---|
| Story Points | Indicate a story point estimate for the story. Used in release planning and project status reports. |
| Acceptance Criteria | Identify acceptance criteria for the story. |
| Lead Time | View the number of hours from the time the story was entered (Date Entered field) to the time it entered the Done workflow state. |
| Cycle Time | View the number of hours from the time the story entered the In Progress workflow state to the time it entered the Done state. |
The default Requirement item type was renamed to Story/Task in the Scrum Template. A User Story is a specific Story/Task type.
Tasks represent specific pieces of a user story that the team needs to implement to complete the story. In practice, user stories are broken down into tasks. A Task is a specific Story/Task type. Tasks contain the following fields.
| Field | Use to: |
|---|---|
| Lead Time | View the number of hours from the time the story was entered (Date Entered field) to the time it entered the Done workflow state. |
| Cycle Time | View the number of hours from the time the story entered the In Progress workflow state to the time it entered the Done workflow state. |
Tip: You can configure requirements to support multiple item types. For each type, you can configure the fields to capture data, permissions for adding, editing, and updating items, and how items are visually represented in Helix ALM. For example, in the Scrum Template, User Stories and Tasks are types of requirements.
Test cases represent a set of conditions (pre-conditions, test steps, expected results, etc.) used to determine if a specific product is working as expected. Test cases contain the following fields.
| Field | Use to: |
|---|---|
| Type | Identify the type of test case. |
| Automated test | Identify if the test is automated. Can use to integrate automated testing tools with Helix ALM. |
| Estimated run time | Estimate the run time for the test. Used for release planning and project status reporting. |
| Expected Results | Document results a tester running the test can expect. You can also add this information in the test case steps. |
Manual test runs represent executable instances of a test case to run against the tested application. In practice, every time a test case needs to be run, a manual test run should be created. Manual test runs contain the following fields.
| Field | Use to: |
|---|---|
| Type | View the test type. Populated by the related test case and cannot be changed. |
| Automated test | View if the test is automated. Populated by the related test case and cannot be changed. |
| Estimated run time | View an estimated run time for the test. Populated by the related test case and cannot be changed. |
| Expected Results | View or document results a tester running the test can expect. This information may also be included in the manual test run steps. |
| Manual Test Run Set | Group related manual test runs to make tracking and reporting on test results easier. Populated when manual test runs are generated and cannot be changed. |
Defects represent product issues, feature requests, customer complaints or other feedback from internal or external users. Defects contain the following fields.
| Field | Use to: |
|---|---|
| Disposition | Identify the defect disposition, such as Open - Reviewed, Hold, or Fix in Future Release. Hidden for Administration and Engineering security groups. |
| Type | Identify the defect type, such as Incorrect Functionality, Cosmetic, or Feature Request. |
| Priority | Identify the defect priority. |
| Product | Identify the product the defect was found in. |
| Component | Identify the product component the defect was found in. |
| Severity | Identify the defect severity. |
| Reported by | Capture who found the defect, the product version it was found in, and details about how it was found. Each defect can have multiple Reported by records if more than one person submits the same defect or feature request. |
| Lead Time | View the number of hours from the time the defect was entered (Date Entered field) to the time it entered the Resolved workflow state. |
| Cycle Time | View the number of hours from the time the defect entered the Accepted workflow state to the time it entered the Resolved state. |
The default Issue item type was renamed to Defect in the Scrum Template.
