Project Management

This page describes details for our project management.

Definition of Done

  • Issue created in Jira with a clear description.

  • Labels added to issue.

  • Release versions set on issue - both quarter scope and product release if relevant.

  • Work items completed.

  • Work products linked to Jira issue (eg: code change, released software, blog, research report).

  • Acceptance Criteria was met.

  • Work products reviewed by Testing Farm team and stakeholders.

  • Feedback from review implemented and all stakeholders satisfied.

Please see the Contribution Guide for details about tools, code, and style.

Jira Issues

Testing Farm is managed via Jira available at https://issues.redhat.com/browse/TFT. The instance is currently Red Hat only, we are talking about opening up the issues to the public.

All issues must use the following types:

  • Epic - for large features, consisting of multiple issues

  • Story - for new features and user stories

  • Bug - for bug fixes

  • Task - for other tasks

Using subtasks is optional. Subtasks should not set any labels or be in any releases. In case a subtask should be in release, convert it to a regular issue.

Story Points

As the team, we agreed on the following story points estimation for our team.

Story Points Complexity Risk Uncertainty Time Effort

1

Task is extremely simple to do. There is a minimal amount of work that needs to be done.

Low.

None. No consultation needed.

Takes an hour or less.

4

Task is simple to do. The acceptance criteria are short and can be satisfied with ease.

Low.

None. No consultation needed.

Takes a few hours.

8

Task is fairly simple, but can have some smaller complex parts. The acceptance criteria are short and can be satisfied with ease.

Medium.

Little. May need consultation.

Takes a day.

20

Task is a fairly simple, but can have more complex parts. The acceptance criteria are a bit larger, but can be satisfied.

Medium.

Medium. May need consultation.

Takes a couple of days.

40

Task has more complex parts, but should still be manageble. The acceptance criteria are larger, but well understood. Most probably should be split into multiple tasks for better tracking.

High.

Medium. Will need consultation or multiple consultations.

Takes a week or more then a week.

160

Task is very complex. Cannot be delivered as is and must be split into smaller tasks.

High.

Team has fuzzy idea how long will it take.

Takes a month or more months.

Estimation

We use the "Easy Agile Planning Poker" Jira plugin. Any team member may vote. If there is only one vote, it’s value will be used.

Because our story points are based on a time work estimation (in hours), we estimate using the following principles:

  • The time in hours we estimate to spend on activities to resolve the issue, i.e. coding, writing documentation, discussion, getting more information from peers, resolving review comments, investigating and resolving CI issues caused by the change, etc.

  • We exclude from the estimate waiting times, i.e. waiting for CI pipelines to finish, waiting for outages, waiting for blocker issues to resolve, waiting for reviews etc.

  • The time during these events should be ideally spent on other tasks.

The Epic Jira issue type does not have an estimation. When another Jira issue type is converted to an Epic, the estimation will be removed by Jira automation.

Acceptance Criteria

Following acceptance criteria is automatically added to all Jira issues:

(off) Feature or Bug Fix is implemented
(off) Deliverables reviewed
(off) Unit tests were created or updated
(off) Integration tests created or updated
(off) Deployed to all environments
(off) Configuration added/changed and cherry-picked to production
(off) Documentation written or updated
(off) Release notes updated

Acceptance criteria can be extended with a checklist of subtasks in case you do not want to use subtasks for this.

Following states are allowed for the acceptance criteria items:

(off) not started
(on) started
(/) done
(-) not applicable

Jira Labels

This is a list of agreed labels to be used with our issues.

Service related:

  • BaseOS-CI

  • TestingFarm

Workflow related:

  • ErrorBudget

  • Escalation

  • KnownIssue

  • NeedsTriage

  • NewFeature

  • Release

  • support-request - not following the naming standard due to Always Ready RHEL agreement

Planning related:

  • BucketCommunity - Address public issues, support Fedora community, address tmt MR queue, organize TTI mini-summit, presentations, etc.

  • BucketContinuity - Continuing to run the business, supporting existing onboarded users and improving experience of the service for them.

  • BucketEffectivity - Improving effectivity of the team, like onboarding new team members and longer term code contributors, improving automation, etc.

  • BucketMigration - Migrating users to Testing Farm or implementing new features, so they can onboard.

  • BucketStrategic - Supporting strategic initiatives like Image Mode, RHEL on GitLab, RHEL on Konflux or RHEL AI.

  • BucketTechnicalDebt - Addressing bugs or technical debt in our code.

Event related:

  • Gathering

  • DevConf

  • QECamp

General components:

  • Composes

  • Infrastructure

  • Monitoring

  • ProdSec

  • ProjectManagement

  • ReportPortal

  • tft-admin

  • tmt

  • STI

Testing Farm components:

  • API

  • Artemis

  • Artifacts

  • CLI

  • Dispatcher

  • Oculus

  • Worker

  • PublicRanch

  • RedHatRanch

Gluetool related:

  • Gluetool

  • GuestSetup

BaseOS CI components:

  • Covscan

  • Restraint

  • IntegrationTests

  • wow

Users:

  • convert2rhel

  • CRC

  • FedoraCI

  • ImageBuilder

  • JavaQE

  • KernelQE

  • KVMQE

  • OSCI

  • Packit

  • RHCOS

  • ImageModeRHEL

  • RHIVOS

  • SecureSign

  • SystemRoles

  • Upgrades

  • VirtQE

  • Zuul

Cloud related:

  • AWS

  • Azure

  • Beaker

  • GCP

  • IBMCloud

  • Openstack

Extended issue type:

  • BestPractice

  • BreakingChange

  • Contribution

  • Cost

  • Demo

  • Documentation

  • Presentation

  • Regression

  • TechnicalDebt

  • Usability

  • UserRequest

Tickets we want to monitor in other jira projects than TFT:

  • TFT

Sprint Guidelines

  • Urgent operational issues will be added to the sprint immediately.

  • Other issues closed during the sprint will be added to the sprint after discussion when the sprint is being closed.

  • Adding any other issues or modifying story points is forbidden without discussion and team agreement.

  • During sprint planning, select a set of issues for team members who finish their sprint work early.

  • If you finished all your issues, please talk to the team if anybody needs a helping hand with issues in the current sprint.

  • If a task assigned to you is not closed by the end of the sprint, but much work has been done and or time has been spent on it, consider changing the task description and/or title, closing it, and creating a triggered task for the unfinished work. Please discuss with the team and/or PO.

Rotating Roles

The team uses rotating roles to distribute responsibilities and ensure shared ownership of team processes. Each role is assigned to a team member for a defined period, typically one sprint.

Sprint Lead

The Sprint Lead is responsible for monitoring the sprint progression and ensuring the sprint stays up to date.

Responsibilities:

  • Monitor sprint progress daily and ensure the sprint board reflects the current state of work.

  • Ensure all issues in the sprint have correct status (To Do, In Progress, Done).

  • Remind team members to update their issues when needed.

  • Facilitate resolution of blockers by bringing them to the team’s attention.

  • Prepare the sprint review at the end of the sprint, summarizing completed work and carry-overs:

    • Review all issues in the sprint and categorize them as completed or carry-over.

    • Create a summary listing key achievements and any unfinished work with reasons.

    • Example: "Sprint 2026-02.1: Completed 12 issues including TFT-1234 (new API endpoint) and TFT-1235 (bug fix). Carry-over: TFT-1236 (blocked by external dependency), TFT-1237 (scope increased mid-sprint)."

  • Coordinate with the Product Owner on any scope changes or urgent additions.

  • Ensure the sprint retrospective is scheduled and conducted.

PTO and Time Off

This section describes the procedure for handling Paid Time Off (PTO) and other absences.

Before Your Absence

  • Announce your planned absence in the Testing Farm Meeting Notes.

  • Update your personal calendar with out-of-office event to automatically decline meetings.

  • Update the shared TFT calendar reflecting your absence

  • If you have any ongoing work or tasks in progress:

    • Update the status and add comments to your Jira issues describing the current state.

    • If the work cannot wait until your return, coordinate with a team member for handover.

    • Consider unassigning yourself from issues if someone else will take over.

During Your Absence

  • Consider setting an out-of-office auto-reply on your email.

  • Consider your status as "Away" or "OOO" in Slack.

  • You are not expected to monitor work communications during your time off.

After Your Return

  • Check the team chat and meeting notes for any important updates.

  • Review your assigned Jira issues and update their status.

  • Reach out to the team if you need a summary of what happened during your absence.

Handover Checklist

When handing over work before an absence:

  • Provide context on all in-progress tasks.

  • Share access to any relevant documentation or resources.

  • Identify and communicate any deadlines that fall during your absence.

  • Introduce the covering team member to any external stakeholders if necessary.