Agile Process
This document describes how the Testing Farm team works using Scrum. It focuses on practical team processes, responsibilities, and ceremonies. Tooling- and issue-specific conventions are documented in Project management page.
Process Overview
The team uses Scrum with a 2-week sprint cadence.
-
Sprint length: 2 weeks
-
Sprint boundary: Monday → Monday
-
Retrospective after each sprint
-
All work is tracked in Jira
-
One shared team backlog
The process is intentionally lightweight and adapted to long-term team experience.
Roles
Product Owner (František Lachman)
The Product Owner is responsible for prioritization and alignment, not day-to-day execution.
Responsibilities:
-
Communicates priorities with related projects and internal customers
-
Translates higher-level goals into epics and issues
-
Organizes and maintains the backlog at a level above individual sprint execution
-
Helps define quarterly and sprint priorities together with the team
Scrum Master (Marek Beneš)
The Scrum Master role exists to support the Scrum process. Historically, responsibilities were shared across the team; a dedicated Scrum Master role is being introduced.
Responsibilities:
-
Ensures Scrum ceremonies happen and are effective
-
Helps remove process-level impediments
-
Supports continuous improvement of team workflow
|
If you need to change the scope of the active sprint (adding, removing, or re-prioritizing work), contact the Product Owner. Changes affecting sprint execution should be discussed together with the Scrum Master when applicable. |
Sprint Lead (Rotating Role)
Each sprint has a rotating Sprint Lead. The Sprint Lead is responsible for monitoring the sprint progression and ensuring the sprint stays up to date. More details on project managemant page.
Release Leads
There are three Release Leads (one per product). Details are documented separately and not repeated here.
In short, Release Leads:
-
Ensure important changes are reviewed and completed in time
-
Prepare and send release notes
-
Deploy releases to production
The goal is to move towards one release per sprint for all products.
Jira Workflow
Jira is the single source of truth for work tracking.
Core workflow:
-
New
-
Backlog
-
In Progress
-
Code Review
-
Closed
Blocked issues:
-
Are typically blocked by another ticket or upstream issue
-
Should be visible and actively tracked by the Sprint Lead
-
Blocked by field is used for description or link
Estimation
The team uses story points.
-
Story points are mandatory for all tickets included in the current sprint
Story point definition and scale are documented here: Story Points
Definition of Done
The Definition of Done is documented here: DoD
Meetings & Ceremonies
All meetings are expected to be attended by the whole team. Attendance is not strictly enforced due to parallel responsibilities (e.g. TMT, RHEL testing, RHIVOS), but participation is expected when possible.
If someone cannot attend, an asynchronous update is expected.
Daily Standup
-
Frequency: every workday
-
Purpose: synchronize work, surface blockers, followup discussions after standup if needed
-
Format: synchronous (Google Meet), async update on Slack if needed
Team Meeting
-
Frequency: twice per week
-
Purpose: broader technical or organizational topics not suited for standup
Triage Meeting
-
Frequency: weekly
-
Participants: team only (no Product Owner)
-
Purpose:
-
triage new issues
-
handle incoming support requests
-
decide what belongs in backlog vs. ad-hoc work
-
Many triaged items are support-requests related to provided services.
Sprint Planning
-
Frequency: once per sprint
-
Purpose:
-
define sprint scope
-
confirm priorities
-
ensure all planned tickets are estimated
-
limit scope based on expected team velocity
-