From 13c9197af44854cf04c72b9345e9c9fcc42a8694 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Franti=C5=A1ek=20Lachman?= Date: Tue, 23 Apr 2024 15:17:49 +0200 Subject: [PATCH 01/10] Document team agile practices, meetings and board --- docs/board.md | 142 +++++++++++++++++++++++++++++++++++++++++++++++ docs/meetings.md | 51 +++++++++++++++++ docs/roles.md | 38 +++++++++++++ 3 files changed, 231 insertions(+) create mode 100644 docs/board.md create mode 100644 docs/meetings.md create mode 100644 docs/roles.md diff --git a/docs/board.md b/docs/board.md new file mode 100644 index 0000000..c7e900e --- /dev/null +++ b/docs/board.md @@ -0,0 +1,142 @@ +# Packit Kanban Board + +The current board is publicly available at https://github.com/orgs/packit/projects/7. + +## Card states (=board columns) + +### new + +This is a column where all the new cards are added (automatically for public repositories, via GitHub action for private ones). At the beginning of each [Standup meeting](./meetings#Standup), a [triaging](#Triage) of new unassigned cards is happening resulting in either moving the card away or assigning a team member to further investigate and finish the triaging. Also, a card can be returned to the `new` column if we realise the card is not clear or needs attention (e.g. to check for relevancy). This can happen when going through the old cards during [Standup](./meetings#Standup). + +### backlog + +This is a pile of cards that have been basically categorized but are not a current priority (present in the `priority-backlog`). The order of this column is not maintained. + +### priority-backlog + +This is an ordered list of categorized cards that the team is considering for the next work. The priority is based on impact, user value, urgency and the current team plans and capacity. The team is revisiting the epic-level priorities on a quarterly level and the cards in the `priority-backlog` should be done in 3 months. This means the number of cards needs to be maintained below ~50. + +### refined + +This column consists of cards prepared to be worked on next when someone has a free capacity. The tasks should be actionable right away and doable by anyone. To get a card to this state a [refining process](#Refine) is used. + +### in-progress + +When a card is taken by someone from a `refined` column, it is assigned to that person and moved to this column. This is the list of cards that are being actively worked on. + +### in-review + +These tasks are nearly finished, being reviewed and polished. + +### done + +This is the column where all the done cards result. + +## Card labels + +Here is a list of labels we use to categorize cards to help ourselves navigate through the backlog and plan our work. +Note that there is no priority label since this consists of multiple factors like impact and gain. Combined with the urgency, our current plans (based on demand) and capacity, this is visible from the place on the board. + +### Area + +These labels help to group related cards across all the projects. The area can determine a target git-forge (e.g. `area/github`/`are/gitlab`), service being integrated (e.g. `area/testing-farm` or `area/copr`) or a shared code-level logic (e.g. `area/config` or `area/database`). + +### Complexity + +This is a rough estimation of how much time is expected for this card to be done. Mainly to separate epics from single cards. -- work consisting of multiple tasks, usually taking more time and being discussed in quarterly meetings. + +### Gain + +This determines the value it gives to affected users. + +- `gain/high`: significant change for the user, e.g.: + - New users can start using Packit. + - Significant time is saved for the user when the task is done. + - A user might stop using Packit when not available. +- `gain/low`: change not so important to start/stop using Packit, e.g.: + - If `workaround-exists` (separate label). + - User can fully benefit from Packit without the card being done. + +### Impact + +These labels determine the size of a user group affected by this card combined with a frequency. To make this comparable, it is based on generic user roles like `upstream-developer` or `fedora-maintainer`. This means we won't mark a card as high-impactful when all (but a few in reality) users of a rear functionality are affected. + +This needs to be combined with frequency -- this means how often they can benefit from a new feature or how often an issue is hit. + +- `impact/high`: Many users are affected by this card and the occurrence is significant. +- `impact/low`: The card affects only a few users and/or rarely-used features. The issues are not hit often. + +### `blocked` + +This label is used to show that we can't move this card/work forward because of an external reason. For a reason, this is not a board state since the card can be blocked on various states of the development. + +### `resource-reduction` + +This label marks tasks that can lead to better resource utilisation. (Without significant functional loss, fewer resources can be spent.) + +### `discuss` + +This label helps us gather cards to be discussed in weekly architecture meetings. + +### Action items / for discussion (Section to be removed before merging.) + +#### To remove: + +- `needs-info` (`new` state) +- `needs-design` (not used) +- `pinned` +- `triaged` +- `invalid` +- `RHOSC`, `GSOC` +- Is `has-release-notes` still relevant? +- Do `wontfix` and `invalid` labels provide any value when the issue is closed and marked as not planned with a comment? + +#### Edits + +- Rename `area/refactor` to `area/technical-dept`. +- Rename `testing` to `area/testing` + +#### Questions + +- Do we need complexity? +- Do we need `kind/documentation`? (We have a separate project for doc-only cards and don't mention this explicitly on other cards.) + +## Grooming process cheat sheet: + +## Triage + +(=process new cards and make basic categorization) + +1. Triaging + 1. **_Is the card not valid or out of our scope?_** => Politely provide reasoning and close the issue as not planned. + 2. **_Do we have a related card for this?_** => Link the relevant cards, and add to an epic if applicable. Link and close in favour of a duplicate issue if applicable. + 3. **_Do we need to get more information from the requester? Is it necessary for a team-member to take a look?_** => Assign a person to continue with the discussion and leave it in the `new` column. + 4. **_Is the task actionable and we are in general sure what the card is about and which way the solution be chosen?_** => Enhance the title and description if needed and move outside of the `new` column. + 5. **_Does the issue come from an external person and there is a chance of contributing this?_** => Politely ask if the requester won't be able to contribute this with our help. +2. Labelling + 1. **_Can we get a new user or allow a new user to start using a feature? Can this determine for the user if Packit will be used in the future?_** => Add `gain/high` label. + **_Is there a workaround or the feature is not significant to the user?_** => use `gain/low`. + 2. **_Is this affecting many users from a role group (e.g. Fedora maintainers, Upstream developers,...)? Can this bring a significant number of new users?_** => Add `impact/high`, add `impact/low` otherwise. + 3. Add a `demo` label for tasks that are worth presenting to the team or users. + 4. Add `area/*`, `kind/*` and other suitable labels if needed. + 5. Add a deadline if applicable. +3. Prioritising + 1. **_Is there a strict deadline? Did we break anything crucial? Are we significantly blocking users?_** => [Refine the card](#Refine) right away and move to the `refined` column. + 2. **_Is there a `gain/high` and `impact/high` label? Do we need/want to finish this within ~3 months? Is this part of our current high-level plans for the quarter?_** => Move to the `priority-backlog` column. + 3. **_Is there a workaround? Doesn't the task make a user start/stop using Packit? Or, otherwise. _** => move to the `backlog` column. + +## Refine + +(=prepare card for work) + +1. Clarification, make sure that + 1. It is clear what needs to be done and there is a definition of done. + 2. Everyone in the team understands the task to a distance to be able to work on the card themselves. + (Suggest splitting or brainstorming + 3. No one has any objections to the card itself or the chosen way. +2. Vote about the time estimation (return to the previous step in case new concerns are raised). + 1. Voting is done via hands and by using a Fibonacci sequence number. + 2. If the vote is not united, discuss the reasons and the card in more detail so there is an agreement. + 3. Split the card if the team is thinking about picking `8` (=more than a week) as a time estimate. + 4. Fill the result in card details. + 5. Move the card to the `refined` column and reorder if needed. diff --git a/docs/meetings.md b/docs/meetings.md new file mode 100644 index 0000000..5c8ec01 --- /dev/null +++ b/docs/meetings.md @@ -0,0 +1,51 @@ +# Meetings + +Our team meetings are organised similarly each week. We have standup meetings on Monday, Tuesday and Thursday morning and all the other team meetings happen on Thursdays to make our team schedule compact. + +## Standups + +We have standups 3 times a week (Mondays, Tuesdays and Thursdays) to talk about issues we are facing and what we are planning to work on next. Reserve the other 2 days for focus time. + +1. Each standup, we start with checking the new cards in our [Kanban board](https://github.com/orgs/packit/projects/7). On Mondays, we also go through the blocked cards and cards that haven't had any progress for a while to see if we can do anything with them. +2. To avoid stale issues, we discuss also one least recently updated issue from the backlog and check if it's still relevant. +3. We follow with the statuses -- everyone quickly shares what they were working on recently, what are working on and planning to do next. Also if there are any issues or blockers found on the way. This should be a monologue to make the most of the time. Any topic requiring more discussion is left to be discussed elsewhere (separate discussion/meeting or [architecture meeting](TBD link)) or discussed at the end of the standup. +4. For each standup, we have a standup question defined to engage a bit. Everyone answers the question after providing a status. It can be any warm-up question or short activity. Sometimes, it's just for fun, sometimes it allows us to show our current mood or energy level. This also makes us know others more building a stronger team together. +5. So-called post-standup topics are discussed. To not disturb statuses, any announcement or topic requiring a discussion/response is left to the end of the meeting. + +## Architecture meeting + +To not make standup meetings too long, we've separated the longer discussion into a weekly organised meeting. As the name suggests, the main goal of this meeting is to discuss technical or architectural topics but there is a place to discuss anything. The topics are collected beforehand in a shared document. Alternatively, anyone can add a "discuss" label to an issue. + +[Kanban lead](TBD) facilitates the discussion and shows a 5-minute timer for each topic (can be reset if everyone agrees to continue with a discussion). Kanban lead is also responsible for note-taking and making a clear conclusion from the discussion including the clear action items. Anyone is welcome to help with the notes since sometimes it's hard to facilitate discussion and make notes at one time. + +Meetings are safe space. There are no dumb ideas or stupid questions - anyone can ask if they don’t understand something. + +:::tip +If there is a strong decision needed, let people provide feedback also offline (either before or after the meeting). Some people might prefer written communication and/or asynchronous communication. Allow them to participate so the best decision is chosen. +::: + +## Refinement meeting + +Weekly meetings to prepare our next cards to work on. This is not to **_plan_** the work for the next week as done in Scrum. Kanban is based on a stream of cards going through the board columns. This activity is about moving the card from the top of the backlog (a priority one in our case) into the _refined_ column so they can be taken by anyone to start the real work. + +When refining, we need to make sure that the card is clearly defined (i.e. **anyone** can work on the card), there is a clear definition of done and the card is doable in 5 or fewer days. + +The discussion starts with a quick introduction of the card (done by a [Kanban lead](TBD) or a person the most familiar with the task). The card is being updated and the discussion continues until we agree it's clear and can be done in 5 days or less -- to help ourselves reach this agreement, there is a voting going on. We used to do a thumbs-up/down for the following questions: + +1. Is this card clear? +2. Is this doable in 5 days or less? + +Since there wasn't much disagreement and discussion, we switched to Scrum-like voting by hand about story points. (A difference in story points helps us better find a difference in the understanding.) We collect the story points but it's not the main reason why we do the voting. Be respectful when asking people why they've chosen a different story point number. It's to help everyone with the understanding and also to share the possible risks, not to put anyone in a spot! + +Mark cards worth demoing with a `demo` label – either for the public or for the team to share knowledge. + +At the end of the meeting, make sure the order (=priority) of the cards in the _refined_ column is right and respects our priorities as shown on the [epic board](https://github.com/orgs/packit/projects/7/views/29). + +## Retrospectives + +Bi-weekly meetings to get a sense of how everyone feels. This is a safe space -- feel free to share anything openly and also be open to listening to others. + +Miro board is created by the Kanban Lead leading the Retrospective at the beginning of the week (ideally Monday morning) to provide time for adding notes to the board in advance. +There's a default Miro board template prepared, but any activity or board can be used to make it more interesting. + +Action items from the previous retro board should be included to be discussed and checked. diff --git a/docs/roles.md b/docs/roles.md new file mode 100644 index 0000000..4c185ea --- /dev/null +++ b/docs/roles.md @@ -0,0 +1,38 @@ +# Packit team roles + +In our team, we have a few statically assigned roles but as much as possible is shared within a team in the form of weekly-rotated roles. We don't rotate the roles of Product Owner and Technical Leader to give the team a long-term perspective. Having both a Product Owner and a Technical Leader allows us to balance the user-targeted view with the implementation perspective. Despite of having those two roles assigned, everyone is welcome to help (e.g. Community Shepherd helps with the daily communication with our users). + +## Product Owner + +The role of the Product Owner is here to represent the user perspective and make sure the work being done by the team benefits our users. They also define the vision and high-level architecture of the project. The main liaison with stakeholders and consumers. + +## Technical Leader + +A technical leader understands the project and all its parts to an extent to be able to make technical decisions or drive the team to make them in a timely and reasonable manner. Responsible for the technical solution being scalable, efficient and secure. Works with PO on breaking down epics into smaller tasks. Responsible for tracking the development status and making sure things go hand in hand with the quarterly plans. + +## Weekly roles + +Here are the roles that are rotated each week. +(Check [this page](./weekly-roles) for the automation we use for it.) +The specific tasks are defined in the form of [issues](https://github.com/packit/agile/issues?q=is%3Aissue+is%3Aopen+label%3Aroles). + +:::note +This is our specific and currently used setup tweaked to our needs and the current number of team members. +We update this now and then but the basic structure and idea stay the same. +::: + +### Service Guru + +This person is responsible for a weekly deployment of Packit service and other related activities (e.g. a blog post). + +### Community Shepherd + +Community Shepherd is present on our communication channels and available to help people or forward questions to other team members. + +### Release Responsible + +The person who does the releases of our projects (both on GitHub and in Fedora). + +### Kanban Lead + +Kanban lead is a moderator of all the [meetings](./meetings) during the week and prepares them (e.g. a standup question or a retrospective board/activity). From 2a16f037b88589e7f4da96e22db324f124e382e1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Franti=C5=A1ek=20Lachman?= Date: Tue, 7 Jan 2025 11:10:08 +0100 Subject: [PATCH 02/10] Apply suggestions from code review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Matej Focko Co-authored-by: Laura Barcziová <49026743+lbarcziova@users.noreply.github.com> --- docs/board.md | 38 +++++++++++++++++++++----------------- docs/meetings.md | 26 ++++++++++++++------------ docs/roles.md | 10 ++++++---- 3 files changed, 41 insertions(+), 33 deletions(-) diff --git a/docs/board.md b/docs/board.md index c7e900e..d1f87f4 100644 --- a/docs/board.md +++ b/docs/board.md @@ -2,44 +2,44 @@ The current board is publicly available at https://github.com/orgs/packit/projects/7. -## Card states (=board columns) +## Card states (board columns) -### new +### `new` -This is a column where all the new cards are added (automatically for public repositories, via GitHub action for private ones). At the beginning of each [Standup meeting](./meetings#Standup), a [triaging](#Triage) of new unassigned cards is happening resulting in either moving the card away or assigning a team member to further investigate and finish the triaging. Also, a card can be returned to the `new` column if we realise the card is not clear or needs attention (e.g. to check for relevancy). This can happen when going through the old cards during [Standup](./meetings#Standup). +This is a column where all the new cards are added (automatically for public repositories, via GitHub action for private ones). At the beginning of each [Standup meeting](./meetings#Standup), a [triaging](#Triage) of new unassigned cards happens resulting in either moving the card away into one of the other states or assigning a team member to further investigate and finish the triaging. Also, a card can be returned to the `new` column if we realise the card is not clear or needs attention (e.g. to check for relevancy). This can happen when going through the old cards during [Standup](./meetings#Standup). -### backlog +### `backlog` This is a pile of cards that have been basically categorized but are not a current priority (present in the `priority-backlog`). The order of this column is not maintained. -### priority-backlog +### `priority-backlog` This is an ordered list of categorized cards that the team is considering for the next work. The priority is based on impact, user value, urgency and the current team plans and capacity. The team is revisiting the epic-level priorities on a quarterly level and the cards in the `priority-backlog` should be done in 3 months. This means the number of cards needs to be maintained below ~50. -### refined +### `refined` This column consists of cards prepared to be worked on next when someone has a free capacity. The tasks should be actionable right away and doable by anyone. To get a card to this state a [refining process](#Refine) is used. -### in-progress +### `in-progress` When a card is taken by someone from a `refined` column, it is assigned to that person and moved to this column. This is the list of cards that are being actively worked on. -### in-review +### `in-review` These tasks are nearly finished, being reviewed and polished. -### done +### `done` This is the column where all the done cards result. ## Card labels Here is a list of labels we use to categorize cards to help ourselves navigate through the backlog and plan our work. -Note that there is no priority label since this consists of multiple factors like impact and gain. Combined with the urgency, our current plans (based on demand) and capacity, this is visible from the place on the board. +Note that there is no priority label since this consists of multiple factors like _impact_ and _gain_. Combined with the urgency, our current plans (based on demand) and capacity, this is visible from the place on the board. ### Area -These labels help to group related cards across all the projects. The area can determine a target git-forge (e.g. `area/github`/`are/gitlab`), service being integrated (e.g. `area/testing-farm` or `area/copr`) or a shared code-level logic (e.g. `area/config` or `area/database`). +These labels help to group related cards across all the projects. The area can determine a target git-forge (e.g. `area/github`/`area/gitlab`), service being integrated (e.g. `area/testing-farm` or `area/copr`) or a shared code-level logic (e.g. `area/config` or `area/database`). ### Complexity @@ -93,7 +93,7 @@ This label helps us gather cards to be discussed in weekly architecture meetings #### Edits -- Rename `area/refactor` to `area/technical-dept`. +- Rename `area/refactor` to `area/technical-debt`. - Rename `testing` to `area/testing` #### Questions @@ -105,14 +105,18 @@ This label helps us gather cards to be discussed in weekly architecture meetings ## Triage -(=process new cards and make basic categorization) +:::note + +Process of handling new cards and categorizing them. + +::: 1. Triaging 1. **_Is the card not valid or out of our scope?_** => Politely provide reasoning and close the issue as not planned. 2. **_Do we have a related card for this?_** => Link the relevant cards, and add to an epic if applicable. Link and close in favour of a duplicate issue if applicable. 3. **_Do we need to get more information from the requester? Is it necessary for a team-member to take a look?_** => Assign a person to continue with the discussion and leave it in the `new` column. - 4. **_Is the task actionable and we are in general sure what the card is about and which way the solution be chosen?_** => Enhance the title and description if needed and move outside of the `new` column. - 5. **_Does the issue come from an external person and there is a chance of contributing this?_** => Politely ask if the requester won't be able to contribute this with our help. + 4. **_Is the task actionable and we are in general sure what the card is about and which way the solution be chosen?_** => Enhance the title and description, if needed, and move outside of the `new` column. + 5. **_Does the issue come from an external person and there is a chance of contributing this?_** => Politely ask if the requester would be able to contribute this with our help. 2. Labelling 1. **_Can we get a new user or allow a new user to start using a feature? Can this determine for the user if Packit will be used in the future?_** => Add `gain/high` label. **_Is there a workaround or the feature is not significant to the user?_** => use `gain/low`. @@ -131,8 +135,8 @@ This label helps us gather cards to be discussed in weekly architecture meetings 1. Clarification, make sure that 1. It is clear what needs to be done and there is a definition of done. - 2. Everyone in the team understands the task to a distance to be able to work on the card themselves. - (Suggest splitting or brainstorming + 2. Everyone in the team understands the task to an extent of being able to work on the card themselves. + (Suggest splitting (i.e. _breakdown_) or brainstorming, if needed.) 3. No one has any objections to the card itself or the chosen way. 2. Vote about the time estimation (return to the previous step in case new concerns are raised). 1. Voting is done via hands and by using a Fibonacci sequence number. diff --git a/docs/meetings.md b/docs/meetings.md index 5c8ec01..5b86e41 100644 --- a/docs/meetings.md +++ b/docs/meetings.md @@ -4,24 +4,26 @@ Our team meetings are organised similarly each week. We have standup meetings on ## Standups -We have standups 3 times a week (Mondays, Tuesdays and Thursdays) to talk about issues we are facing and what we are planning to work on next. Reserve the other 2 days for focus time. +We have standups 3 times a week (Mondays, Tuesdays and Thursdays) to talk about what we have been working on, issues we are facing and what we are planning to work on next. Reserve the other 2 days for focus time. -1. Each standup, we start with checking the new cards in our [Kanban board](https://github.com/orgs/packit/projects/7). On Mondays, we also go through the blocked cards and cards that haven't had any progress for a while to see if we can do anything with them. -2. To avoid stale issues, we discuss also one least recently updated issue from the backlog and check if it's still relevant. +1. Each standup, we start with checking the new cards in our [Kanban board](https://github.com/orgs/packit/projects/7). On Mondays, we also go through the blocked cards, cards that haven't had any progress for a while to see if we can do anything with them and cards approaching their due-date. +2. To avoid stale issues, we also discuss one of the least recently updated issues from the backlog and check if it's still relevant. 3. We follow with the statuses -- everyone quickly shares what they were working on recently, what are working on and planning to do next. Also if there are any issues or blockers found on the way. This should be a monologue to make the most of the time. Any topic requiring more discussion is left to be discussed elsewhere (separate discussion/meeting or [architecture meeting](TBD link)) or discussed at the end of the standup. -4. For each standup, we have a standup question defined to engage a bit. Everyone answers the question after providing a status. It can be any warm-up question or short activity. Sometimes, it's just for fun, sometimes it allows us to show our current mood or energy level. This also makes us know others more building a stronger team together. -5. So-called post-standup topics are discussed. To not disturb statuses, any announcement or topic requiring a discussion/response is left to the end of the meeting. +4. For each standup, we have a standup question defined to engage a bit. Everyone answers the question after providing a status. It can be any warm-up question or short activity. Sometimes, it's just for fun, sometimes it allows us to show our current mood or energy level. This also makes us know others more, building a stronger team together. +5. So-called post-standup topics are discussed. To not disturb statuses, any announcement or topic requiring a small discussion/response is left to the end of the meeting. ## Architecture meeting -To not make standup meetings too long, we've separated the longer discussion into a weekly organised meeting. As the name suggests, the main goal of this meeting is to discuss technical or architectural topics but there is a place to discuss anything. The topics are collected beforehand in a shared document. Alternatively, anyone can add a "discuss" label to an issue. +To not make standup meetings too long, we've separated the longer discussions into a weekly organised meeting. As the name suggests, the main goal of this meeting is to discuss technical or architectural topics but there is a place to discuss anything. The topics are collected beforehand in a shared document. Alternatively, anyone can add a "discuss" label to an issue. -[Kanban lead](TBD) facilitates the discussion and shows a 5-minute timer for each topic (can be reset if everyone agrees to continue with a discussion). Kanban lead is also responsible for note-taking and making a clear conclusion from the discussion including the clear action items. Anyone is welcome to help with the notes since sometimes it's hard to facilitate discussion and make notes at one time. +[Kanban Lead](TBD) facilitates the discussion and shows a 5-minute timer for each topic (can be reset if everyone agrees to continue with a discussion). Kanban Lead is also responsible for note-taking and making a clear conclusion from the discussion including the clear action items. Anyone is welcome to help with the notes since sometimes it's hard to facilitate discussion and make notes at the same time. -Meetings are safe space. There are no dumb ideas or stupid questions - anyone can ask if they don’t understand something. +Meetings are a safe space. There are no dumb ideas or stupid questions - anyone can ask if they don’t understand something. :::tip -If there is a strong decision needed, let people provide feedback also offline (either before or after the meeting). Some people might prefer written communication and/or asynchronous communication. Allow them to participate so the best decision is chosen. + +If there is a strong decision needed, let people provide feedback also offline (either before or after the meeting). Some people might prefer written communication and/or asynchronous communication. Allow them to participate, so the best decision is chosen. + ::: ## Refinement meeting @@ -30,16 +32,16 @@ Weekly meetings to prepare our next cards to work on. This is not to **_plan_** When refining, we need to make sure that the card is clearly defined (i.e. **anyone** can work on the card), there is a clear definition of done and the card is doable in 5 or fewer days. -The discussion starts with a quick introduction of the card (done by a [Kanban lead](TBD) or a person the most familiar with the task). The card is being updated and the discussion continues until we agree it's clear and can be done in 5 days or less -- to help ourselves reach this agreement, there is a voting going on. We used to do a thumbs-up/down for the following questions: +The discussion starts with a quick introduction of the card (done by a [Kanban Lead](TBD) or a person the most familiar with the task). The card is being updated and the discussion continues until we agree it's clear and can be done in 5 days or less -- to help ourselves reach this agreement, there is a voting going on. We used to do a thumbs-up/down for the following questions: 1. Is this card clear? 2. Is this doable in 5 days or less? -Since there wasn't much disagreement and discussion, we switched to Scrum-like voting by hand about story points. (A difference in story points helps us better find a difference in the understanding.) We collect the story points but it's not the main reason why we do the voting. Be respectful when asking people why they've chosen a different story point number. It's to help everyone with the understanding and also to share the possible risks, not to put anyone in a spot! +Since there wasn't much disagreement and discussion, we switched to Scrum-like voting by hand about story points. (A difference in story points helps us better find a difference in the understanding.) We collect the story points but it's not the main reason why we do the voting. Be respectful when asking people why they've chosen a different story point number. It's to help everyone with the understanding and also to share the possible risks, not to put someone on the spot! Mark cards worth demoing with a `demo` label – either for the public or for the team to share knowledge. -At the end of the meeting, make sure the order (=priority) of the cards in the _refined_ column is right and respects our priorities as shown on the [epic board](https://github.com/orgs/packit/projects/7/views/29). +At the end of the meeting, make sure the order (=priority) of the cards in the _refined_ column is right and respects our priorities as shown on the [epic board](https://github.com/orgs/packit/projects/7/views/29), but also considers any urgent tasks (e.g. maintenance like renewing certificates). ## Retrospectives diff --git a/docs/roles.md b/docs/roles.md index 4c185ea..34822ca 100644 --- a/docs/roles.md +++ b/docs/roles.md @@ -1,14 +1,14 @@ # Packit team roles -In our team, we have a few statically assigned roles but as much as possible is shared within a team in the form of weekly-rotated roles. We don't rotate the roles of Product Owner and Technical Leader to give the team a long-term perspective. Having both a Product Owner and a Technical Leader allows us to balance the user-targeted view with the implementation perspective. Despite of having those two roles assigned, everyone is welcome to help (e.g. Community Shepherd helps with the daily communication with our users). +In our team, we have a few statically assigned roles, but as much as possible is shared within a team in the form of weekly-rotated roles. We don't rotate the roles of _Product Owner_ and _Technical Leader_ to give the team a long-term perspective. Having both a Product Owner and a Technical Leader allows us to balance the user-targeted view with the implementation perspective. Despite of having those two roles assigned, everyone is welcome to help (e.g. Community Shepherd helps with the daily communication with our users). ## Product Owner -The role of the Product Owner is here to represent the user perspective and make sure the work being done by the team benefits our users. They also define the vision and high-level architecture of the project. The main liaison with stakeholders and consumers. +The role of the Product Owner is to represent the user perspective and make sure the work being done by the team benefits our users. They also define the vision and high-level architecture of the project. The main liaison with stakeholders and consumers. ## Technical Leader -A technical leader understands the project and all its parts to an extent to be able to make technical decisions or drive the team to make them in a timely and reasonable manner. Responsible for the technical solution being scalable, efficient and secure. Works with PO on breaking down epics into smaller tasks. Responsible for tracking the development status and making sure things go hand in hand with the quarterly plans. +A Technical Leader understands the project and all its parts to an extent to be able to make technical decisions or drive the team to make them in a timely and reasonable manner. Responsible for the technical solution being scalable, efficient and secure. Works with PO on breaking down epics into smaller tasks. Responsible for tracking the development status and making sure things go hand in hand with the quarterly plans. ## Weekly roles @@ -17,8 +17,10 @@ Here are the roles that are rotated each week. The specific tasks are defined in the form of [issues](https://github.com/packit/agile/issues?q=is%3Aissue+is%3Aopen+label%3Aroles). :::note + This is our specific and currently used setup tweaked to our needs and the current number of team members. -We update this now and then but the basic structure and idea stay the same. +We update this now and then, but the basic structure and idea stay the same. + ::: ### Service Guru From 9f15914429b7c1532cbb33d265ebe2d378683c0b Mon Sep 17 00:00:00 2001 From: Frantisek Lachman Date: Fri, 10 Jan 2025 10:00:12 +0100 Subject: [PATCH 03/10] Make the board page cover Kanban process Signed-off-by: Frantisek Lachman --- docs/{board.md => kanban.md} | 54 +++++++++++++++++++----------------- 1 file changed, 29 insertions(+), 25 deletions(-) rename docs/{board.md => kanban.md} (90%) diff --git a/docs/board.md b/docs/kanban.md similarity index 90% rename from docs/board.md rename to docs/kanban.md index d1f87f4..2034f8a 100644 --- a/docs/board.md +++ b/docs/kanban.md @@ -1,51 +1,55 @@ -# Packit Kanban Board +# How Packit team does Kanban? + +Packit team follows a Kanban methodology but not use just a board with `todo`/`wip`/`done` columns. We have couple of extra columns and rules. Let's take a look: + +## Packit Kanban Board The current board is publicly available at https://github.com/orgs/packit/projects/7. -## Card states (board columns) +### Card states (board columns) -### `new` +#### `new` This is a column where all the new cards are added (automatically for public repositories, via GitHub action for private ones). At the beginning of each [Standup meeting](./meetings#Standup), a [triaging](#Triage) of new unassigned cards happens resulting in either moving the card away into one of the other states or assigning a team member to further investigate and finish the triaging. Also, a card can be returned to the `new` column if we realise the card is not clear or needs attention (e.g. to check for relevancy). This can happen when going through the old cards during [Standup](./meetings#Standup). -### `backlog` +#### `backlog` -This is a pile of cards that have been basically categorized but are not a current priority (present in the `priority-backlog`). The order of this column is not maintained. +This is a pile of cards that have been basically categorized but are not a current priority (present in the `priority-backlog`), or it is not within our capacity to finish them within next 3 months. The order of this column is not maintained. -### `priority-backlog` +#### `priority-backlog` This is an ordered list of categorized cards that the team is considering for the next work. The priority is based on impact, user value, urgency and the current team plans and capacity. The team is revisiting the epic-level priorities on a quarterly level and the cards in the `priority-backlog` should be done in 3 months. This means the number of cards needs to be maintained below ~50. -### `refined` +#### `refined` This column consists of cards prepared to be worked on next when someone has a free capacity. The tasks should be actionable right away and doable by anyone. To get a card to this state a [refining process](#Refine) is used. -### `in-progress` +#### `in-progress` When a card is taken by someone from a `refined` column, it is assigned to that person and moved to this column. This is the list of cards that are being actively worked on. -### `in-review` +#### `in-review` These tasks are nearly finished, being reviewed and polished. -### `done` +#### `done` This is the column where all the done cards result. -## Card labels +### Card labels Here is a list of labels we use to categorize cards to help ourselves navigate through the backlog and plan our work. Note that there is no priority label since this consists of multiple factors like _impact_ and _gain_. Combined with the urgency, our current plans (based on demand) and capacity, this is visible from the place on the board. -### Area +#### Area These labels help to group related cards across all the projects. The area can determine a target git-forge (e.g. `area/github`/`area/gitlab`), service being integrated (e.g. `area/testing-farm` or `area/copr`) or a shared code-level logic (e.g. `area/config` or `area/database`). -### Complexity +#### Complexity This is a rough estimation of how much time is expected for this card to be done. Mainly to separate epics from single cards. -- work consisting of multiple tasks, usually taking more time and being discussed in quarterly meetings. -### Gain +#### Gain This determines the value it gives to affected users. @@ -57,7 +61,7 @@ This determines the value it gives to affected users. - If `workaround-exists` (separate label). - User can fully benefit from Packit without the card being done. -### Impact +#### Impact These labels determine the size of a user group affected by this card combined with a frequency. To make this comparable, it is based on generic user roles like `upstream-developer` or `fedora-maintainer`. This means we won't mark a card as high-impactful when all (but a few in reality) users of a rear functionality are affected. @@ -66,21 +70,21 @@ This needs to be combined with frequency -- this means how often they can benefi - `impact/high`: Many users are affected by this card and the occurrence is significant. - `impact/low`: The card affects only a few users and/or rarely-used features. The issues are not hit often. -### `blocked` +#### `blocked` This label is used to show that we can't move this card/work forward because of an external reason. For a reason, this is not a board state since the card can be blocked on various states of the development. -### `resource-reduction` +#### `resource-reduction` This label marks tasks that can lead to better resource utilisation. (Without significant functional loss, fewer resources can be spent.) -### `discuss` +#### `discuss` This label helps us gather cards to be discussed in weekly architecture meetings. -### Action items / for discussion (Section to be removed before merging.) +#### Action items / for discussion (Section to be removed before merging.) -#### To remove: +##### To remove: - `needs-info` (`new` state) - `needs-design` (not used) @@ -91,19 +95,19 @@ This label helps us gather cards to be discussed in weekly architecture meetings - Is `has-release-notes` still relevant? - Do `wontfix` and `invalid` labels provide any value when the issue is closed and marked as not planned with a comment? -#### Edits +##### Edits - Rename `area/refactor` to `area/technical-debt`. - Rename `testing` to `area/testing` -#### Questions +##### Questions - Do we need complexity? - Do we need `kind/documentation`? (We have a separate project for doc-only cards and don't mention this explicitly on other cards.) -## Grooming process cheat sheet: +### Grooming process cheat sheet: -## Triage +### Triage :::note @@ -129,7 +133,7 @@ Process of handling new cards and categorizing them. 2. **_Is there a `gain/high` and `impact/high` label? Do we need/want to finish this within ~3 months? Is this part of our current high-level plans for the quarter?_** => Move to the `priority-backlog` column. 3. **_Is there a workaround? Doesn't the task make a user start/stop using Packit? Or, otherwise. _** => move to the `backlog` column. -## Refine +### Refine (=prepare card for work) From d14bbebd4bfbc49f781d67d80cb27b9fd8636206 Mon Sep 17 00:00:00 2001 From: Frantisek Lachman Date: Fri, 10 Jan 2025 10:48:18 +0100 Subject: [PATCH 04/10] Document Story Point scale Signed-off-by: Frantisek Lachman --- docs/kanban.md | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/docs/kanban.md b/docs/kanban.md index 2034f8a..b861028 100644 --- a/docs/kanban.md +++ b/docs/kanban.md @@ -82,6 +82,20 @@ This label marks tasks that can lead to better resource utilisation. (Without si This label helps us gather cards to be discussed in weekly architecture meetings. +### Story points + +Despite using Kanban, we use the Fibonnacci sequence numbers as story points similarly to Scrum to estimate the card's complexity, uncertanity and effort. As described in the [section about Refinement meeting](meetings#refinement), the main purpose of the sizing in our team is to brought up discussion and find differences in task understanding. As with regular Kanban where all the cards are made similar in time, we split all cards that can take more than a few days by not allowing cards with more than 5 story points. + +#### Story point scale + +This is how we think about the scale: + +- `1`: Very simple card done in a few hours. Everything is clear and straightforward. No unknown at all. +- `2`: Easy card, a bit of thought required, but the ask is clear, well defined and should take one a day. Nothing unexpected is not expected. +- `3`: Average task requiring a couple of days to finish. A bit of unknown is possible but usually does not require much interaction with anyone else and the outcome is clearly defined. +- `5`: Well-defined but complex card that can take a week to finis h. Can spread across multiple projects, usually requires some extra discussion and updating as part of the review process. +- `8`: This is a complex task that can take someone more than a week to finish. We avoid such cards since such cards usually contains a lot of unknowns and can easily take multiple weeks to finish for real. + #### Action items / for discussion (Section to be removed before merging.) ##### To remove: @@ -122,7 +136,7 @@ Process of handling new cards and categorizing them. 4. **_Is the task actionable and we are in general sure what the card is about and which way the solution be chosen?_** => Enhance the title and description, if needed, and move outside of the `new` column. 5. **_Does the issue come from an external person and there is a chance of contributing this?_** => Politely ask if the requester would be able to contribute this with our help. 2. Labelling - 1. **_Can we get a new user or allow a new user to start using a feature? Can this determine for the user if Packit will be used in the future?_** => Add `gain/high` label. + 1. **_Can we get a new Packit user or allow an already onboarded user to start using another Packit's functionality? Can this influence the decision of a user whether Packit will be integrated in the future?_** => Add `gain/high` label. **_Is there a workaround or the feature is not significant to the user?_** => use `gain/low`. 2. **_Is this affecting many users from a role group (e.g. Fedora maintainers, Upstream developers,...)? Can this bring a significant number of new users?_** => Add `impact/high`, add `impact/low` otherwise. 3. Add a `demo` label for tasks that are worth presenting to the team or users. From 9b95a1d662c043ae85e5455e0c044c5f68d9f522 Mon Sep 17 00:00:00 2001 From: Frantisek Lachman Date: Fri, 10 Jan 2025 10:48:46 +0100 Subject: [PATCH 05/10] Add links and references to the meeting page Signed-off-by: Frantisek Lachman --- docs/meetings.md | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/docs/meetings.md b/docs/meetings.md index 5b86e41..ce9ed6a 100644 --- a/docs/meetings.md +++ b/docs/meetings.md @@ -1,22 +1,26 @@ # Meetings -Our team meetings are organised similarly each week. We have standup meetings on Monday, Tuesday and Thursday morning and all the other team meetings happen on Thursdays to make our team schedule compact. +Our team meetings are organised similarly each week. We have [Standup](#standup) meetings on Monday, Tuesday and Thursday morning and all the other team meetings happen on Thursdays to make our team schedule compact. + +:::tip +As part of our role-rotation practice, all the regular weekly meetings are facilities by a Kanban lead](./roles#kanban-lead) of the week. +::: ## Standups We have standups 3 times a week (Mondays, Tuesdays and Thursdays) to talk about what we have been working on, issues we are facing and what we are planning to work on next. Reserve the other 2 days for focus time. -1. Each standup, we start with checking the new cards in our [Kanban board](https://github.com/orgs/packit/projects/7). On Mondays, we also go through the blocked cards, cards that haven't had any progress for a while to see if we can do anything with them and cards approaching their due-date. +1. Each standup, we start with checking the new cards in our [Kanban board](./kanban#packit-kanban-board). On Mondays, we also go through the blocked cards, cards that haven't had any progress for a while to see if we can do anything with them and cards approaching their due-date. 2. To avoid stale issues, we also discuss one of the least recently updated issues from the backlog and check if it's still relevant. -3. We follow with the statuses -- everyone quickly shares what they were working on recently, what are working on and planning to do next. Also if there are any issues or blockers found on the way. This should be a monologue to make the most of the time. Any topic requiring more discussion is left to be discussed elsewhere (separate discussion/meeting or [architecture meeting](TBD link)) or discussed at the end of the standup. +3. We follow with the statuses -- everyone quickly shares what they were working on recently, what are working on and planning to do next. Also if there are any issues or blockers found on the way. This should be a monologue to make the most of the time. Any topic requiring more discussion is left to be discussed elsewhere (separate discussion/meeting or [architecture meeting](#architecture)) or discussed at the end of the standup. 4. For each standup, we have a standup question defined to engage a bit. Everyone answers the question after providing a status. It can be any warm-up question or short activity. Sometimes, it's just for fun, sometimes it allows us to show our current mood or energy level. This also makes us know others more, building a stronger team together. 5. So-called post-standup topics are discussed. To not disturb statuses, any announcement or topic requiring a small discussion/response is left to the end of the meeting. -## Architecture meeting +## Architecture -To not make standup meetings too long, we've separated the longer discussions into a weekly organised meeting. As the name suggests, the main goal of this meeting is to discuss technical or architectural topics but there is a place to discuss anything. The topics are collected beforehand in a shared document. Alternatively, anyone can add a "discuss" label to an issue. +To not make [Standup](#standup) meetings too long, we've separated the longer discussions into a weekly organised meeting. As the name suggests, the main goal of this meeting is to discuss technical or architectural topics but there is a place to discuss anything. The topics are collected beforehand in a shared document. Alternatively, anyone can add a [`discuss` label](./kanban#discuss) to an issue. -[Kanban Lead](TBD) facilitates the discussion and shows a 5-minute timer for each topic (can be reset if everyone agrees to continue with a discussion). Kanban Lead is also responsible for note-taking and making a clear conclusion from the discussion including the clear action items. Anyone is welcome to help with the notes since sometimes it's hard to facilitate discussion and make notes at the same time. +[Kanban Lead](./roles#kanban-lead) facilitates the discussion and shows a 5-minute timer for each topic (can be reset if everyone agrees to continue with a discussion). [Kanban Lead](./roles#kanban-lead) is also responsible for note-taking and making a clear conclusion from the discussion including the clear action items. Anyone is welcome to help with the notes since sometimes it's hard to facilitate discussion and make notes at the same time. Meetings are a safe space. There are no dumb ideas or stupid questions - anyone can ask if they don’t understand something. @@ -28,18 +32,15 @@ If there is a strong decision needed, let people provide feedback also offline ( ## Refinement meeting -Weekly meetings to prepare our next cards to work on. This is not to **_plan_** the work for the next week as done in Scrum. Kanban is based on a stream of cards going through the board columns. This activity is about moving the card from the top of the backlog (a priority one in our case) into the _refined_ column so they can be taken by anyone to start the real work. +Weekly meetings to prepare our next cards to work on. This is not to **_plan_** the work for the next week as done in Scrum. Kanban is based on a stream of cards going through [the board columns](./kanban#card-states-board-columns). This activity is about moving the card from the top of the backlog (a [priority one](./kanban#priority-backlog) in our case) into the [_refined_ column](./kanban#refined) by following [our refinement process](./kanban#refine). +Basically it's about making sure the task is clearly defined and understood by the team members so they can be taken by anyone to start the real work. -When refining, we need to make sure that the card is clearly defined (i.e. **anyone** can work on the card), there is a clear definition of done and the card is doable in 5 or fewer days. - -The discussion starts with a quick introduction of the card (done by a [Kanban Lead](TBD) or a person the most familiar with the task). The card is being updated and the discussion continues until we agree it's clear and can be done in 5 days or less -- to help ourselves reach this agreement, there is a voting going on. We used to do a thumbs-up/down for the following questions: +The discussion starts with a quick introduction of the card (done by a [Kanban Lead](./roles#kanban-lead) or a person the most familiar with the task). The card is being updated and the discussion continues until we agree it's clear and can be done in 5 days or less -- to help ourselves reach this agreement, there is a voting going on. We used to do a thumbs-up/down for the following questions: 1. Is this card clear? 2. Is this doable in 5 days or less? -Since there wasn't much disagreement and discussion, we switched to Scrum-like voting by hand about story points. (A difference in story points helps us better find a difference in the understanding.) We collect the story points but it's not the main reason why we do the voting. Be respectful when asking people why they've chosen a different story point number. It's to help everyone with the understanding and also to share the possible risks, not to put someone on the spot! - -Mark cards worth demoing with a `demo` label – either for the public or for the team to share knowledge. +Since there wasn't much disagreement and discussion, we switched to Scrum-like voting by hand about [story points](./kanban#story-points). (A [difference in story points](./kanban#story-point-scale) helps us better find a difference in the understanding.) We collect the story points but it's not the main reason why we do the voting. Be respectful when asking people why they've chosen a different story point number. It's to help everyone with the understanding and also to share the possible risks, not to put anyone in a spot! At the end of the meeting, make sure the order (=priority) of the cards in the _refined_ column is right and respects our priorities as shown on the [epic board](https://github.com/orgs/packit/projects/7/views/29), but also considers any urgent tasks (e.g. maintenance like renewing certificates). @@ -47,7 +48,7 @@ At the end of the meeting, make sure the order (=priority) of the cards in the _ Bi-weekly meetings to get a sense of how everyone feels. This is a safe space -- feel free to share anything openly and also be open to listening to others. -Miro board is created by the Kanban Lead leading the Retrospective at the beginning of the week (ideally Monday morning) to provide time for adding notes to the board in advance. +Miro board is created by the [Kanban Lead](./roles#kanban-lead) leading the Retrospective at the beginning of the week (ideally Monday morning) to provide time for adding notes to the board in advance. There's a default Miro board template prepared, but any activity or board can be used to make it more interesting. Action items from the previous retro board should be included to be discussed and checked. From 3edee44959c7a0f912c4d73312f2c6e78e528246 Mon Sep 17 00:00:00 2001 From: Frantisek Lachman Date: Fri, 10 Jan 2025 10:54:10 +0100 Subject: [PATCH 06/10] Add Chief of monitors role Signed-off-by: Frantisek Lachman --- docs/roles.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/roles.md b/docs/roles.md index 34822ca..47e089d 100644 --- a/docs/roles.md +++ b/docs/roles.md @@ -35,6 +35,10 @@ Community Shepherd is present on our communication channels and available to hel The person who does the releases of our projects (both on GitHub and in Fedora). +### Chief of monitors + +The person responsible for checking the state of the service via metrics and Sentry alerts. + ### Kanban Lead Kanban lead is a moderator of all the [meetings](./meetings) during the week and prepares them (e.g. a standup question or a retrospective board/activity). From 671fb2c5e830660ef873a7eaf0d0bf630427f368 Mon Sep 17 00:00:00 2001 From: Frantisek Lachman Date: Fri, 10 Jan 2025 10:58:44 +0100 Subject: [PATCH 07/10] Mention we check the epics on our retro meetings Signed-off-by: Frantisek Lachman --- docs/meetings.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/meetings.md b/docs/meetings.md index ce9ed6a..b0380d9 100644 --- a/docs/meetings.md +++ b/docs/meetings.md @@ -52,3 +52,5 @@ Miro board is created by the [Kanban Lead](./roles#kanban-lead) leading the Retr There's a default Miro board template prepared, but any activity or board can be used to make it more interesting. Action items from the previous retro board should be included to be discussed and checked. + +At the end of the meeting, we revisit our [epics](https://github.com/orgs/packit/projects/7/views/29) and how we are standing on our planned epics for the quarter. From 2dfe4abb41530bf4c9c2230f0f671bb1e65b0aaf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Franti=C5=A1ek=20Lachman?= Date: Fri, 10 Jan 2025 13:57:25 +0100 Subject: [PATCH 08/10] Apply suggestions from code review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Matej Focko Co-authored-by: Nikola Forró Co-authored-by: Laura Barcziová <49026743+lbarcziova@users.noreply.github.com> --- docs/kanban.md | 28 ++++++++++++++-------------- docs/meetings.md | 8 +++++--- docs/roles.md | 4 ++-- 3 files changed, 21 insertions(+), 19 deletions(-) diff --git a/docs/kanban.md b/docs/kanban.md index b861028..fa674b7 100644 --- a/docs/kanban.md +++ b/docs/kanban.md @@ -1,6 +1,6 @@ # How Packit team does Kanban? -Packit team follows a Kanban methodology but not use just a board with `todo`/`wip`/`done` columns. We have couple of extra columns and rules. Let's take a look: +Packit team follows the Kanban methodology but does not just use a board with `todo`/`wip`/`done` columns. We have a couple of extra columns and rules. Let's take a look! ## Packit Kanban Board @@ -10,19 +10,19 @@ The current board is publicly available at https://github.com/orgs/packit/projec #### `new` -This is a column where all the new cards are added (automatically for public repositories, via GitHub action for private ones). At the beginning of each [Standup meeting](./meetings#Standup), a [triaging](#Triage) of new unassigned cards happens resulting in either moving the card away into one of the other states or assigning a team member to further investigate and finish the triaging. Also, a card can be returned to the `new` column if we realise the card is not clear or needs attention (e.g. to check for relevancy). This can happen when going through the old cards during [Standup](./meetings#Standup). +This is a column where all the new cards are added (automatically for public repositories, via GitHub action for private ones). At the beginning of each [Standup meeting](./meetings#Standup), a [triaging](#Triage) of new unassigned cards happens resulting in either moving the card away into one of the other states or assigning a team member to further investigate and finish the triaging. Also, the card can be moved back to the `new` column if we realise the card is not clear or needs attention (e.g. to verify its relevance). This can happen when going through old cards during [Standup](./meetings#Standup). #### `backlog` -This is a pile of cards that have been basically categorized but are not a current priority (present in the `priority-backlog`), or it is not within our capacity to finish them within next 3 months. The order of this column is not maintained. +This is a pile of cards that have been basically categorized but are not a current priority (such cards are present in the `priority-backlog`), or it is not within our capacity to finish them within the next 3 months. The order of this column is not maintained. #### `priority-backlog` -This is an ordered list of categorized cards that the team is considering for the next work. The priority is based on impact, user value, urgency and the current team plans and capacity. The team is revisiting the epic-level priorities on a quarterly level and the cards in the `priority-backlog` should be done in 3 months. This means the number of cards needs to be maintained below ~50. +This is an ordered list of categorized cards that the team is considering for the upcoming work. Their priority is determined based on impact, user value, urgency and current team plans and capacity. The team revisits the epic-level priorities quarterly and the cards in the `priority-backlog` should be finished in 3 months. This means the number of cards needs to be maintained to be below ~50. #### `refined` -This column consists of cards prepared to be worked on next when someone has a free capacity. The tasks should be actionable right away and doable by anyone. To get a card to this state a [refining process](#Refine) is used. +This column consists of cards prepared to be worked on next when someone has capacity. The tasks should be actionable right away and doable by anyone. To get a card to this state a [refining process](#Refine) is used. #### `in-progress` @@ -47,7 +47,7 @@ These labels help to group related cards across all the projects. The area can d #### Complexity -This is a rough estimation of how much time is expected for this card to be done. Mainly to separate epics from single cards. -- work consisting of multiple tasks, usually taking more time and being discussed in quarterly meetings. +This is a rough estimation of how much time is expected for this card to be done. Mainly to separate epics from single cards. Epics covers work consisting of multiple tasks, usually taking more time and being discussed in quarterly meetings. #### Gain @@ -63,7 +63,7 @@ This determines the value it gives to affected users. #### Impact -These labels determine the size of a user group affected by this card combined with a frequency. To make this comparable, it is based on generic user roles like `upstream-developer` or `fedora-maintainer`. This means we won't mark a card as high-impactful when all (but a few in reality) users of a rear functionality are affected. +These labels determine the size of a user group affected by this card combined with a frequency. To make this comparable, it is based on generic user roles like `upstream-developer` or `fedora-maintainer`. This means we won't mark a card as high-impactful when all (but a few in reality) users of a rare functionality are affected. This needs to be combined with frequency -- this means how often they can benefit from a new feature or how often an issue is hit. @@ -84,17 +84,17 @@ This label helps us gather cards to be discussed in weekly architecture meetings ### Story points -Despite using Kanban, we use the Fibonnacci sequence numbers as story points similarly to Scrum to estimate the card's complexity, uncertanity and effort. As described in the [section about Refinement meeting](meetings#refinement), the main purpose of the sizing in our team is to brought up discussion and find differences in task understanding. As with regular Kanban where all the cards are made similar in time, we split all cards that can take more than a few days by not allowing cards with more than 5 story points. +Despite using Kanban, we use the Fibonnacci sequence numbers as story points similarly to Scrum to estimate the card's complexity, uncertanity and effort. As described in the [section about Refinement meeting](meetings#refinement), the main purpose of the sizing in our team is to bring up discussion and find differences in the task understanding. As with regular Kanban where all the cards are made similar in time, we split all cards that can take more than a few days by not allowing cards with more than 5 story points. #### Story point scale This is how we think about the scale: - `1`: Very simple card done in a few hours. Everything is clear and straightforward. No unknown at all. -- `2`: Easy card, a bit of thought required, but the ask is clear, well defined and should take one a day. Nothing unexpected is not expected. +- `2`: Easy card, a bit of thought required, but the ask is clear, well defined and should take one day. Complications are not expected. - `3`: Average task requiring a couple of days to finish. A bit of unknown is possible but usually does not require much interaction with anyone else and the outcome is clearly defined. -- `5`: Well-defined but complex card that can take a week to finis h. Can spread across multiple projects, usually requires some extra discussion and updating as part of the review process. -- `8`: This is a complex task that can take someone more than a week to finish. We avoid such cards since such cards usually contains a lot of unknowns and can easily take multiple weeks to finish for real. +- `5`: Well-defined but complex card that can take a week to finish. Can span across multiple projects, usually requires some extra discussion and updating as part of the review process. +- `8`: This is a complex task that can take someone more than a week to finish. We avoid such cards since such cards usually contain a lot of unknowns and can easily take multiple weeks to finish for real. #### Action items / for discussion (Section to be removed before merging.) @@ -133,13 +133,13 @@ Process of handling new cards and categorizing them. 1. **_Is the card not valid or out of our scope?_** => Politely provide reasoning and close the issue as not planned. 2. **_Do we have a related card for this?_** => Link the relevant cards, and add to an epic if applicable. Link and close in favour of a duplicate issue if applicable. 3. **_Do we need to get more information from the requester? Is it necessary for a team-member to take a look?_** => Assign a person to continue with the discussion and leave it in the `new` column. - 4. **_Is the task actionable and we are in general sure what the card is about and which way the solution be chosen?_** => Enhance the title and description, if needed, and move outside of the `new` column. + 4. **_Is the task actionable and do we have a clear understanding of the card's purpose and the solution direction??_** => Enhance the title and description, if needed, and move outside of the `new` column. 5. **_Does the issue come from an external person and there is a chance of contributing this?_** => Politely ask if the requester would be able to contribute this with our help. 2. Labelling 1. **_Can we get a new Packit user or allow an already onboarded user to start using another Packit's functionality? Can this influence the decision of a user whether Packit will be integrated in the future?_** => Add `gain/high` label. **_Is there a workaround or the feature is not significant to the user?_** => use `gain/low`. - 2. **_Is this affecting many users from a role group (e.g. Fedora maintainers, Upstream developers,...)? Can this bring a significant number of new users?_** => Add `impact/high`, add `impact/low` otherwise. - 3. Add a `demo` label for tasks that are worth presenting to the team or users. + 2. **_Is this affecting many users from a role group (e.g. Fedora maintainers, Upstream developers, etc.)? Can this bring a significant number of new users?_** => Add `impact/high`, add `impact/low` otherwise. + 3. Add a `demo` label to tasks that are worth presenting to the team or users. 4. Add `area/*`, `kind/*` and other suitable labels if needed. 5. Add a deadline if applicable. 3. Prioritising diff --git a/docs/meetings.md b/docs/meetings.md index b0380d9..4723798 100644 --- a/docs/meetings.md +++ b/docs/meetings.md @@ -3,14 +3,16 @@ Our team meetings are organised similarly each week. We have [Standup](#standup) meetings on Monday, Tuesday and Thursday morning and all the other team meetings happen on Thursdays to make our team schedule compact. :::tip -As part of our role-rotation practice, all the regular weekly meetings are facilities by a Kanban lead](./roles#kanban-lead) of the week. + +As part of our role-rotation practice, all the regular weekly meetings are facilitated by the Kanban Lead](./roles#kanban-lead) of the week. + ::: ## Standups We have standups 3 times a week (Mondays, Tuesdays and Thursdays) to talk about what we have been working on, issues we are facing and what we are planning to work on next. Reserve the other 2 days for focus time. -1. Each standup, we start with checking the new cards in our [Kanban board](./kanban#packit-kanban-board). On Mondays, we also go through the blocked cards, cards that haven't had any progress for a while to see if we can do anything with them and cards approaching their due-date. +1. Each standup, we start with checking the new cards in our [Kanban board](./kanban#packit-kanban-board). On Mondays, we also go through the blocked cards, cards that haven't had any progress for a while to see if any action can be taken and cards approaching their due-date. 2. To avoid stale issues, we also discuss one of the least recently updated issues from the backlog and check if it's still relevant. 3. We follow with the statuses -- everyone quickly shares what they were working on recently, what are working on and planning to do next. Also if there are any issues or blockers found on the way. This should be a monologue to make the most of the time. Any topic requiring more discussion is left to be discussed elsewhere (separate discussion/meeting or [architecture meeting](#architecture)) or discussed at the end of the standup. 4. For each standup, we have a standup question defined to engage a bit. Everyone answers the question after providing a status. It can be any warm-up question or short activity. Sometimes, it's just for fun, sometimes it allows us to show our current mood or energy level. This also makes us know others more, building a stronger team together. @@ -40,7 +42,7 @@ The discussion starts with a quick introduction of the card (done by a [Kanban L 1. Is this card clear? 2. Is this doable in 5 days or less? -Since there wasn't much disagreement and discussion, we switched to Scrum-like voting by hand about [story points](./kanban#story-points). (A [difference in story points](./kanban#story-point-scale) helps us better find a difference in the understanding.) We collect the story points but it's not the main reason why we do the voting. Be respectful when asking people why they've chosen a different story point number. It's to help everyone with the understanding and also to share the possible risks, not to put anyone in a spot! +Since there wasn't much disagreement and discussion, we switched to Scrum-like voting by hand about [story points](./kanban#story-points). (A [difference in story points](./kanban#story-point-scale) helps us better find a difference in the understanding.) We collect the story points but it's not the main reason why we do the voting. Be respectful when asking people why they've chosen a different story point number. It's to help everyone with the understanding and also to share the possible risks, not to put someone on the spot! At the end of the meeting, make sure the order (=priority) of the cards in the _refined_ column is right and respects our priorities as shown on the [epic board](https://github.com/orgs/packit/projects/7/views/29), but also considers any urgent tasks (e.g. maintenance like renewing certificates). diff --git a/docs/roles.md b/docs/roles.md index 47e089d..61d1c55 100644 --- a/docs/roles.md +++ b/docs/roles.md @@ -35,9 +35,9 @@ Community Shepherd is present on our communication channels and available to hel The person who does the releases of our projects (both on GitHub and in Fedora). -### Chief of monitors +### Chief of Monitors -The person responsible for checking the state of the service via metrics and Sentry alerts. +The person responsible for monitoring the state of the service via metrics and alerts (from Sentry or Prometheus). ### Kanban Lead From bc8d062ec394a4feb52c241e250a5f3692b0a34d Mon Sep 17 00:00:00 2001 From: Frantisek Lachman Date: Mon, 13 Jan 2025 13:00:29 +0100 Subject: [PATCH 09/10] Update the story-point definition to match how we use it Signed-off-by: Frantisek Lachman --- docs/kanban.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/kanban.md b/docs/kanban.md index fa674b7..b56a0ac 100644 --- a/docs/kanban.md +++ b/docs/kanban.md @@ -90,8 +90,8 @@ Despite using Kanban, we use the Fibonnacci sequence numbers as story points sim This is how we think about the scale: -- `1`: Very simple card done in a few hours. Everything is clear and straightforward. No unknown at all. -- `2`: Easy card, a bit of thought required, but the ask is clear, well defined and should take one day. Complications are not expected. +- `1`: Very simple card done in ~20 minutes. Everything is clear and straightforward. No unknown at all. +- `2`: Easy card, a bit of thought required, but the ask is clear, well defined and should take at most a day to finish. Complications are not expected. - `3`: Average task requiring a couple of days to finish. A bit of unknown is possible but usually does not require much interaction with anyone else and the outcome is clearly defined. - `5`: Well-defined but complex card that can take a week to finish. Can span across multiple projects, usually requires some extra discussion and updating as part of the review process. - `8`: This is a complex task that can take someone more than a week to finish. We avoid such cards since such cards usually contain a lot of unknowns and can easily take multiple weeks to finish for real. From 7d4a4e753b6b0dff8eb27920b03516b62b2095a4 Mon Sep 17 00:00:00 2001 From: Frantisek Lachman Date: Mon, 13 Jan 2025 13:00:45 +0100 Subject: [PATCH 10/10] Remove action items since all is covered now Signed-off-by: Frantisek Lachman --- docs/kanban.md | 23 ----------------------- 1 file changed, 23 deletions(-) diff --git a/docs/kanban.md b/docs/kanban.md index b56a0ac..e0c79e7 100644 --- a/docs/kanban.md +++ b/docs/kanban.md @@ -96,29 +96,6 @@ This is how we think about the scale: - `5`: Well-defined but complex card that can take a week to finish. Can span across multiple projects, usually requires some extra discussion and updating as part of the review process. - `8`: This is a complex task that can take someone more than a week to finish. We avoid such cards since such cards usually contain a lot of unknowns and can easily take multiple weeks to finish for real. -#### Action items / for discussion (Section to be removed before merging.) - -##### To remove: - -- `needs-info` (`new` state) -- `needs-design` (not used) -- `pinned` -- `triaged` -- `invalid` -- `RHOSC`, `GSOC` -- Is `has-release-notes` still relevant? -- Do `wontfix` and `invalid` labels provide any value when the issue is closed and marked as not planned with a comment? - -##### Edits - -- Rename `area/refactor` to `area/technical-debt`. -- Rename `testing` to `area/testing` - -##### Questions - -- Do we need complexity? -- Do we need `kind/documentation`? (We have a separate project for doc-only cards and don't mention this explicitly on other cards.) - ### Grooming process cheat sheet: ### Triage