Agile Workflow
Some members of the Design Team work on Fedora full-time as part of their role at Red Hat. As part of that role, they follow an Agile workflow to align with the wider company’s way of working. If you are a community contributor who does not work at Red Hat, there is no requirement for you to work in sprints but understanding the system will help you navigate the ticket queue and know what to expect.
What is Agile?
Agile is an approach to project management that breaks work into short, repeating cycles called sprints. Instead of planning everything up front, the team plans a small batch of work, completes it, reviews what happened, and then plans the next batch. This makes it easier to adapt to changing priorities and keep work moving at a steady pace.
A few key terms:
-
Sprint — A fixed time period (in our case, three weeks) during which a set of planned work is completed.
-
Backlog — The full list of tickets that have been accepted but are not yet scheduled for a sprint.
-
Story points — A way of estimating the relative size and complexity of a task. A task worth 1 point is small and straightforward; a task worth 8 points is complex and uncertain.
-
Epic — A large initiative that is too big for a single sprint and is broken down into smaller tickets.
-
Sprint planning — A meeting at the start of each sprint where the team decides which tickets to work on next.
-
Refinement (triage) — A meeting where the team reviews incoming tickets, asks clarifying questions, and assigns labels before work begins.
Sprints
On the Design Team’s organization on the Fedora Forge, work is tracked in three-week sprints. Only members working at Red Hat should add items to the sprint board as this is where they track their work as part of their role.
Items are added to the next sprint during a sprint planning call, attended by the Design Team leads and the scrum master for the CLE (Community Linux Engineering) team.
Ticket Refinement
Every three weeks ahead of a new sprint, Design Team leads meet to triage the ticket queue. During this call, tickets are reviewed and given the appropriate labels. If a ticket needs more information before it can be started, this is the stage where we reach out to the requester.
Tickets are only be triaged and labeled on this call.
Labels
The team uses a set of labels to categorize and prioritize tickets. Here is what each label means:
Acceptance
| Label | Description |
|---|---|
Acceptance: Fedora Design |
A valid ticket that has been accepted by the Fedora Design Team and should be addressed. |
Acceptance: Needs Info |
The ticket needs additional information before it can be triaged. |
Acceptance: Wont fix |
The ticket has been rejected. Reasons may include: budget approval needed, Mindshare approval needed, duplicate or already completed, already part of a larger-scoped plan, redirected to another team, or no resources available. |
Engagement
| Label | Description |
|---|---|
Engagement: Short-term |
A ticket that might require hours to days to work on. |
Engagement: Medium-term |
A ticket that might take days to weeks to work on. |
Engagement: Long-term |
A ticket that might require weeks to months to work on. |
Story Points
Story points estimate the relative size and complexity of a task:
| Label | Description |
|---|---|
points: 01 |
Simple, small, and very little uncertainty. Easy for any team member to pick up and complete quickly. |
points: 02 |
Slightly more complex than a 1. Might involve two or three simple steps, but the outcome is still very clear. |
points: 03 |
Medium-sized with some noticeable complexity. Might require a bit more thought or collaboration, but the steps are well-defined. |
points: 05 |
A significant piece of work with more complexity and a higher degree of uncertainty. May require research, a design discussion, or collaboration across multiple teams. |
points: 08 |
Complex with a lot of uncertainty. Often the largest size considered for a single sprint. Likely requires a detailed breakdown and multiple team members. |
points: 13 |
Any task estimated at 13 or more is considered an Epic. These are too large and uncertain for a single sprint and should be broken down into smaller tickets. |
Priority
| Label | Description |
|---|---|
Priority: High |
Critical work that needs to be addressed next sprint. Often time-sensitive, aligned to Fedora Strategic Initiatives, or a leadership request. |
Priority: Medium |
Important work that should be done soon but is not as urgent as high priority. Likely to be considered for the next 1–2 sprints. |
Priority: Low |
Good to do but not urgent. A candidate for being worked on when there is extra time, or when it rises in importance. Can stay in the backlog for a longer period. |
Status
| Label | Description |
|---|---|
Status: Backlog |
Triaged items that the team is not actively working on. |
Status: In Progress |
Items being actively worked on. |
Status: In Review |
A ticket awaiting review by a team member or the requester. |
Type
| Label | Description |
|---|---|
Type: Epic |
A large initiative broken down into multiple smaller tickets. Epics represent significant features or projects that span multiple sprints. |
Type: Sub Epic |
A smaller segment of work that falls under a larger epic, helping designers break down complex tasks into more manageable parts. |
Type: Request |
A ticket related to an incoming external request, not filed by a designer. |
Other
| Label | Description |
|---|---|
Newbie: Well-documented |
A ticket that someone new to the team could complete. It is well-documented with clear steps. |
Newbie: Needs research |
A ticket that someone new to the team could complete, but will require them to get some help or background first. |
needs review |
The ticket needs to be reviewed and triaged by the Fedora Design Team. |
Want to help? Learn how to contribute to Fedora Docs ›