Handbook: continuous flow for all product groups (4.91.0) (#49500)
This commit is contained in:
Luke Heath
@@ -55,7 +55,7 @@ Ask the user for these if not provided:
|
||||
| Team | Label | GitHub Project |
|
||||
|------|-------|----------------|
|
||||
| Orchestration | `#g-orchestration` | https://github.com/orgs/fleetdm/projects/71/ |
|
||||
| Security & Compliance | `#g-security-compliance` | https://github.com/orgs/fleetdm/projects/97/ |
|
||||
| Supply Chain | `#g-supply-chain` | https://github.com/orgs/fleetdm/projects/97/ |
|
||||
| MDM | `#g-mdm` | https://github.com/orgs/fleetdm/projects/58/ |
|
||||
| Software | `#g-software` | https://github.com/orgs/fleetdm/projects/70/ |
|
||||
| First Impressions | `#g-first-impressions` | https://github.com/orgs/fleetdm/projects/105/ |
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
name: Release QA
|
||||
about: Checklist of required tests prior to release
|
||||
title: 'Release QA:'
|
||||
labels: '#g-orchestration,#g-apple-at-work,#g-power-to-pc,#g-auto-patching,#g-security-compliance,:release'
|
||||
labels: '#g-orchestration,#g-apple-at-work,#g-power-to-pc,#g-auto-patching,#g-supply-chain,#g-byod,:release'
|
||||
assignees: 'xpkoala,andreykizimenko,chrstphr84,Brajim20,marcusallen97,thisisjoegrant'
|
||||
|
||||
---
|
||||
|
||||
@@ -193,7 +193,7 @@ This works because every Fleetie grants edit access to everyone else at Fleet as
|
||||
|
||||
### Shared calendars
|
||||
|
||||
Team calendars are the primary source for sprint rituals; they facilitate the execution of each sprint.
|
||||
Team calendars are the primary source for release rituals; they facilitate the execution of each release cycle.
|
||||
Looking to add, change, or remove a shared calendar? [Create an issue](https://fleetdm.com/handbook/people#contact-us) and the appropriate DRI will reply with feedback.
|
||||
|
||||
### 1:1 meetings
|
||||
@@ -504,7 +504,7 @@ When posting about a personal or philosophical topic that potential Fleet custom
|
||||
- Don't show or say customer names, codenames, or real email addresses.
|
||||
|
||||
**Playback:**
|
||||
- Don't enable closed captions during sprint demo recording (they're added later if needed).
|
||||
- Don't enable closed captions during release demo recording (they're added later if needed).
|
||||
|
||||
|
||||
## Feedback
|
||||
|
||||
@@ -205,7 +205,7 @@ There are many times in which community members, customers, and contributors are
|
||||
|
||||
#### Video
|
||||
|
||||
Fleet uses YouTube to help keep the community up-to-date and informed. These videos facilitate community engagement, provide educational resources, and help share essential information about Fleet and the people using it. Meetings regularly uploaded to YouTube will have a "▶️" emoji prepended to the calendar event title (e.g. "▶️ ☁️🌈 Sprint demos!").
|
||||
Fleet uses YouTube to help keep the community up-to-date and informed. These videos facilitate community engagement, provide educational resources, and help share essential information about Fleet and the people using it. Meetings regularly uploaded to YouTube will have a "▶️" emoji prepended to the calendar event title (e.g. "▶️ ☁️🌈 Release demos!").
|
||||
|
||||
|
||||
## Processing intent signals
|
||||
|
||||
@@ -182,7 +182,7 @@
|
||||
onTargetEarnings: "$80,000 - $160,000"
|
||||
responsibilities: |
|
||||
- ⏫ Work closely with engineering to continually improve overall quality assurance efficiency and effectiveness throughout the product design and engineering process.
|
||||
- 🤝 Collaborate with the engineering managers and quality assurance engineers in the [product groups](https://fleetdm.com/handbook/company/product-groups#current-product-groups), actively participating in some engineering scrum meetings, sprint planning, daily standups, sprint demos, sprint retrospectives, and estimation sessions.
|
||||
- 🤝 Collaborate with the engineering managers and quality assurance engineers in the [product groups](https://fleetdm.com/handbook/company/product-groups#current-product-groups), actively participating in engineering rituals including daily standups, weekly planning, release demos, and release retros.
|
||||
- 🌟 Contribute to the overall success of all [product groups](https://fleetdm.com/handbook/company/product-groups#current-product-groups) by ensuring users receive valuable new features that work as intended.
|
||||
- 🧪 Develop and execute testing plans based on feature specifications, outlining step-by-step actions for each user role to confirm that features function as intended.
|
||||
- 🚀 Perform manual testing of newly developed features on all supported devices, platforms, and browsers, ensuring a seamless user experience.
|
||||
@@ -195,7 +195,7 @@
|
||||
- 🎯 Strong attention to detail and ability to identify inconsistencies or deviations from specifications.
|
||||
- 💡 Excellent communication and collaboration skills, with the ability to work closely with engineering and product teams.
|
||||
- 🌐 Experience in manual testing across various devices, platforms, and browsers.
|
||||
- 🏃♂️ Familiarity with agile development processes and scrum methodologies.
|
||||
- 🏃♂️ Familiarity with agile, continuous-flow development processes.
|
||||
- 👥 A customer-centric mindset, focusing on delivering value and a positive user experience.
|
||||
- 🤝 Collaboration: You work best in a participatory, team-based environment.
|
||||
- 🛠️ Technical: You understand the software development processes.
|
||||
|
||||
+125
-259
@@ -24,8 +24,8 @@ At Fleet, [anyone can contribute](https://fleetdm.com/handbook/company#openness)
|
||||
|
||||
| Role | Responsibilities |
|
||||
|:---------------------|:-----------------|
|
||||
| Product Designer | Wireframe changes to the product, API, configuration surface, GitOps YAML, CLI, and UI. [DRI](https://fleetdm.com/handbook/company/communications#directly-responsible-individuals-dris) for product changes in the current sprint. |
|
||||
| Engineering Manager | Oversee sprint progress, plan and coordinate efforts, technical communication with stakeholders, recruit and mentor engineers. |
|
||||
| Product Designer | Wireframe changes to the product, API, configuration surface, GitOps YAML, CLI, and UI. [DRI](https://fleetdm.com/handbook/company/communications#directly-responsible-individuals-dris) for in-progress product changes. |
|
||||
| Engineering Manager | Oversee day-to-day progress, plan and coordinate efforts, technical communication with stakeholders, recruit and mentor engineers. |
|
||||
| Tech Lead | Oversee day-to-day engineering efforts, assist with user story drafting, support engineers. Capacity is 1/3 support, 2/3 Individual Contributor. |
|
||||
| Quality Assurance | Write and conduct test plans for user stories, report new unreleased bugs, test released bug fixes, conduct smoke testing before each release. |
|
||||
| Software Engineer | [Implement changes](https://fleetdm.com/handbook/company/product-groups#implementing) to the product, provide technical expertise, research user stories, fix bugs, assist with quality assurance. |
|
||||
@@ -33,12 +33,15 @@ At Fleet, [anyone can contribute](https://fleetdm.com/handbook/company#openness)
|
||||
|
||||
## Current product groups
|
||||
|
||||
| Product group | Goal _(value for customers and/or community)_ | Capacity |
|
||||
|:------------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------|:---------|
|
||||
| [Orchestration](#orchestration-group) | Increase and exceed maturity in the [orchestration](https://fleetdm.com/orchestration) product category. | 60 |
|
||||
| [Security & Compliance](#security-compliance-group) | Increase and exceed maturity in the security and compliance product category. | 38 |
|
||||
|
||||
\* The number of [estimated story points](https://fleetdm.com/handbook/product-groups#estimation-points) this group can take on per-sprint under ideal circumstances, used as a baseline number for planning and prioritizing user stories for drafting. In reality, capacity will vary as engineers are on-call, out-of-office, filling in for other product groups, etc.
|
||||
| Product group | Goal _(value for customers and/or community)_ |
|
||||
|:-------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------|
|
||||
| [Orchestration](#orchestration-group) | Increase and exceed maturity in the [orchestration](https://fleetdm.com/orchestration) product category. |
|
||||
| [Supply Chain](#supply-chain-group) | Help customers secure the software and dependencies running on their fleet. |
|
||||
| [Apple @ Work](#apple--work-group) | Increase the number of Apple devices managed by Fleet. |
|
||||
| [Auto Patching](#auto-patching-group) | Reduce the time before software is patched after vulnerabilities are discovered. |
|
||||
| [Power to the PC](#power-to-the-pc-group) | Empower Windows users to fully leverage Fleet as an MDM. |
|
||||
| [BYOD](#byod-group) | Enable Fleet to manage personally-owned Android devices used at work. |
|
||||
| [Website](#website-group) | Increase and exceed Fleet's product maturity goals for fleetdm.com. |
|
||||
|
||||
|
||||
### Orchestration group
|
||||
@@ -67,9 +70,9 @@ The goal of the orchestration group is to increase and exceed [Fleet's product m
|
||||
> The [Slack channel](https://fleetdm.slack.com/archives/C084F4MKYSJ), [kanban release board](https://github.com/orgs/fleetdm/projects/71), and [GitHub label](https://github.com/fleetdm/fleet/labels/%23g-orchestration) for this product group is `#g-orchestration`.
|
||||
|
||||
|
||||
### Security & compliance group
|
||||
### Supply Chain group
|
||||
|
||||
The goal of the security and compliance group is to increase and exceed Fleet's product maturity goals in the security and compliance category.
|
||||
The goal of the Supply Chain group is to help customers secure the software and dependencies running on their fleet, reducing exposure to vulnerabilities and ensuring compliance across the device lifecycle.
|
||||
|
||||
| Responsibility | Human(s) |
|
||||
|:----------------------------------|:--------------------------|
|
||||
@@ -77,9 +80,8 @@ The goal of the security and compliance group is to increase and exceed Fleet's
|
||||
| Engineering Manager | [Sharon Katz](https://www.linkedin.com/in/sharon-katz-45b1b3a/) _([@sharon-fdm](https://github.com/sharon-fdm))_
|
||||
| Tech Lead | [Juan Fernandez](https://www.linkedin.com/in/juan-fdz-hawa/) _([@juan-fdz-hawa](https://github.com/juan-fdz-hawa))_
|
||||
| Quality Assurance | [Marcus Allen](https://www.linkedin.com/in/marcus-a-785b3b7/) _([@MarcusAllen](https://github.com/marcusallen97))_
|
||||
| Software Engineer | [Dante Catalfamo](https://www.linkedin.com/in/dante-catalfamo-a6330412b/) _([@dantecatalfamo](https://github.com/dantecatalfamo))_
|
||||
|
||||
> The [Slack channel](https://fleetdm.slack.com/archives/C09HG9VMRSS), [kanban release board](https://github.com/orgs/fleetdm/projects/97), and [GitHub label](https://github.com/fleetdm/fleet/issues?q=state%3Aopen%20label%3A%23g-security-compliance) for this product group is `#g-security-compliance`.
|
||||
> The [Slack channel](https://fleetdm.slack.com/archives/C09HG9VMRSS), [kanban release board](https://github.com/orgs/fleetdm/projects/97), and [GitHub label](https://github.com/fleetdm/fleet/issues?q=state%3Aopen%20label%3A%23g-supply-chain) for this product group is `#g-supply-chain`.
|
||||
|
||||
**Areas of expertise**:
|
||||
- Software inventory ingestion
|
||||
@@ -94,40 +96,18 @@ The goal of the security and compliance group is to increase and exceed Fleet's
|
||||
|
||||
### Product group capacity
|
||||
|
||||
Product group capacity is allocated based on our [bug open time KPI](https://docs.google.com/spreadsheets/d/1Hso0LxqwrRVINCyW_n436bNHmoqhoLhC8bcbvLPOs9A/edit?usp=sharing). If the average bug open time is greater than 32 days, 50% of each sprint's total capacity is allocated to bugs and [engineering-initiated stories](https://fleetdm.com/handbook/engineering#create-an-engineering-initiated-story). Allocating less than 50% when above our bug open time KPI requires approval from the CEO.
|
||||
Product group capacity is allocated based on our [bug open time KPI](https://docs.google.com/spreadsheets/d/1Hso0LxqwrRVINCyW_n436bNHmoqhoLhC8bcbvLPOs9A/edit?usp=sharing). If the average bug open time is greater than 32 days, 50% of each product group's capacity is allocated to bugs and [engineering-initiated stories](https://fleetdm.com/handbook/engineering#create-an-engineering-initiated-story). Allocating less than 50% when above our bug open time KPI requires approval from the CEO.
|
||||
|
||||
|
||||
## Working groups
|
||||
## Continuous flow
|
||||
|
||||
Like a product group at Fleet, a working group is an arrangement of people from different functions. What makes a working group unique is that it is tasked with achieving a high-impact business goal fast. A working group disbands when the goal is achieved so Fleet stays fast and avoids unnecessary process.
|
||||
Fleet's product groups use a continuous flow process. Well-drafted stories can often be implemented in a day or two, so batching work into fixed multi-week iterations creates unnecessary latency. Instead, issues flow continuously across each product group's board from intake to release.
|
||||
|
||||
Working groups are for important work that needs to be done quickly, when asynchronous work would be too slow.
|
||||
Planning is decoupled from the release boundary. We ship what is complete at each [three-week release](https://fleetdm.com/handbook/company/why-this-way#why-a-three-week-cadence), and fleetd changes follow their own cadence.
|
||||
|
||||
Working groups have their own section in the handbook that includes the name, goal, resources, and contributors. See the commented out section in the handbook for an example.
|
||||
### Roles
|
||||
|
||||
Items to cover in the section:
|
||||
- Name of the working group
|
||||
- Desired business outcomes (goals)
|
||||
- Link to the working group Slack channel and GitHub project
|
||||
- Who is involved. This should include who the DRI is.
|
||||
- Timeline. When will the working group start? When do we think we'll be done by?
|
||||
|
||||
|
||||
### Continuous flow
|
||||
|
||||
Unlike product groups, which use [scrum](#scrum-at-fleet) with 3-week sprints, working groups use a continuous flow process. Well-drafted stories can often be implemented in a day or two, so batching work into 3-week sprints creates unnecessary latency. Instead, issues flow continuously across the working group's board from intake to release.
|
||||
|
||||
#### What is the same
|
||||
|
||||
- **Group roles**: Same group roles and overall responsibilities.
|
||||
- **Standups**: Daily standups become 30 minutes so fast draft can happen.
|
||||
- **Weekly planning**: Sprint planning becomes a weekly 1-hour standup.
|
||||
- **3-week release cadence**: Planning is decoupled from the release boundary. We ship what is complete at each release. fleetd changes follow their own cadence.
|
||||
- **Release retros**: 30-minute retrospective at the end of each 3-week release.
|
||||
|
||||
#### Roles
|
||||
|
||||
Working groups use the same [product group roles](#product-group-roles), with the following continuous-flow responsibilities:
|
||||
Product groups use the [group roles](#product-group-roles) above, with the following continuous-flow responsibilities:
|
||||
|
||||
| Role | Responsibility in continuous flow |
|
||||
|:---------------------|:----------------------------------|
|
||||
@@ -139,9 +119,9 @@ Working groups use the same [product group roles](#product-group-roles), with th
|
||||
|
||||
> While the PD is responsible for ensuring an issue reaches **Ready**, in practice the EM is most often the one physically moving the issue into the column during standup or weekly planning.
|
||||
|
||||
#### DRI areas
|
||||
### DRI areas
|
||||
|
||||
The Roles table covers day-to-day responsibilities. Use this section to determine who owns a given decision within the working group. When two roles overlap, the named DRI has the final call; collaboration is still expected.
|
||||
The Roles table covers day-to-day responsibilities. Use this section to determine who owns a given decision within the product group. When two roles overlap, the named DRI has the final call; collaboration is still expected.
|
||||
|
||||
**Engineering Manager**
|
||||
- Cadence and health of all rituals (standup, weekly planning, release demo, release retro).
|
||||
@@ -175,18 +155,18 @@ The Roles table covers day-to-day responsibilities. Use this section to determin
|
||||
- Whether a story meets minimum criteria for testability before it leaves drafting.
|
||||
- Whether a regression warrants a [release-blocker](#all-bugs) call, in coordination with the EM.
|
||||
|
||||
#### Item types
|
||||
### Item types
|
||||
|
||||
Working groups use the same six [scrum items](#scrum-items) as product groups: user stories, sub-tasks, timeboxes, bugs, quick wins, and reliability issues.
|
||||
Product groups use six [work item types](#work-items): user stories, sub-tasks, timeboxes, bugs, quick wins, and reliability issues.
|
||||
|
||||
#### Board columns
|
||||
### Board columns
|
||||
|
||||
Each working group runs its own GitHub project board with the following columns, ordered left-to-right:
|
||||
Each product group runs its own GitHub project board with the following columns, ordered left-to-right:
|
||||
|
||||
| Column | What it means |
|
||||
|:---|:---|
|
||||
| 📨 Inbox | Any issue labeled with the working group's `#g-*` label lands here. |
|
||||
| 🦢 Full draft | The PD is drafting the issue on the formal [drafting board](https://github.com/orgs/fleetdm/projects/67). The issue stays in this column on the working group board until drafting is complete. |
|
||||
| 📨 Inbox | Any issue labeled with the product group's `#g-*` label lands here. |
|
||||
| 🦢 Full draft | The PD is drafting the issue on the formal [drafting board](https://github.com/orgs/fleetdm/projects/67). The issue stays in this column on the product group board until drafting is complete. |
|
||||
| 🪿 Fast draft | The team hasn't looked at the issue together yet. Drafting happens in-place on the issue, often during standup or async in the group's Slack channel. |
|
||||
| 🚧 Blocked | The issue is stuck and needs discussion before it can move forward. Try to resolve async first; otherwise raise at the next standup. |
|
||||
| 🥚 Ready | The issue has enough detail to start implementation, though not always enough to finish. |
|
||||
@@ -198,7 +178,7 @@ Each working group runs its own GitHub project board with the following columns,
|
||||
|
||||
There are no formal WIP limits today, but the group should watch for buildup in any one column.
|
||||
|
||||
#### Drafting tracks: full draft vs. fast draft
|
||||
### Drafting tracks: full draft vs. fast draft
|
||||
|
||||
The PD decides which stories go through full drafting and is responsible for drafting them. Default to **fast draft**; reserve **full draft** for the highest-risk work. Keeping the full-draft queue small protects PD bandwidth and is a chance for Product Designers to grow their decision-making skills.
|
||||
|
||||
@@ -206,11 +186,11 @@ The PD decides which stories go through full drafting and is responsible for dra
|
||||
|
||||
**Fast draft** is the default for everything else: bug fixes, improvements, well-understood patterns, internal tooling, and most new work. The PD collaborates with the team on what guidance is needed to implement the change. This may be a Figma wireframe, a quick sketch, a bulleted list of changes, or a prototype built directly into the product to choose between options. The PD and EM are responsible for escalating to the HPD and/or CTO if needed. If a customer promise or activation blocker is fast-drafted, it should still be t-shirt sized to reduce risk to the customer.
|
||||
|
||||
#### Estimation
|
||||
### Estimation
|
||||
|
||||
Continuous flow does not use story points or track velocity. [T-shirt sizing](#t-shirt-sizing-capacity-planning) is part of **full draft** and happens async, with anything unresolved discussed at standup. The goal is to minimize the number of stories that require sizing — full draft (and the estimation that comes with it) is reserved for customer promises, activation blockers, and other high-risk work.
|
||||
|
||||
#### How issues move
|
||||
### How issues move
|
||||
|
||||
- **Inbox → Fast draft or Full draft**: every issue moves into a drafting lane. The PD picks the lane (see above). Bugs and priority issues (P2 or greater) are triaged at the daily standup; stories are triaged at the weekly planning meeting.
|
||||
- **Fast draft → Ready**: stories move to **Ready** only during weekly planning, or during standup if they are a priority story (P2 or greater) or if there is nothing else for the group to work on. The team should review fast-draft bugs at standup but may defer them when more pressing items exist.
|
||||
@@ -218,43 +198,28 @@ Continuous flow does not use story points or track velocity. [T-shirt sizing](#t
|
||||
- **Ready → In progress → Ready for review → Awaiting QA**: the assigned engineer is responsible for moving the issue through these columns as work progresses.
|
||||
- **Awaiting QA → Ready for release**: the QA Engineer is responsible for moving the issue from **Awaiting QA** to **Ready for release** once they have verified the change.
|
||||
|
||||
#### Working the board
|
||||
### Working the board
|
||||
|
||||
- **Multiple issues in flight is OK.** Contributors can run several agents in parallel and have many issues open at once. Use judgment; don't start more than you can shepherd through review.
|
||||
- **Pick up unassigned work as you finish in-flight items.** When an issue moves to the next column (e.g. Ready for review), pick the next unassigned item from **Ready**. For bugs, use the standard [bug prioritization order](#bug-prioritization).
|
||||
- **Help finish in-flight work when nothing in Ready is available.** Assist with code review, QA, or sub-issues for active stories.
|
||||
- **Hit a blocker or have a question?** It's okay — blockers happen. Move the issue to **Blocked** and try to resolve it async (in the group's Slack channel, with the relevant collaborator, etc.) rather than waiting for standup. If it isn't resolved async, the next standup is the latest it should go without being addressed.
|
||||
|
||||
#### Daily standup (30 minutes)
|
||||
### Daily standup (30 minutes)
|
||||
|
||||
By-person updates first, then parking lot, then walk the board as time allows. The Inbox is reviewed during standup for bugs and any priority issues (P2 or greater).
|
||||
|
||||
#### Weekly planning (1 hour, Monday)
|
||||
### Weekly planning (1 hour, Monday)
|
||||
|
||||
The working group walks the board **right-to-left**, starting at "Ready for release" and moving back toward "Inbox". Stories in the Inbox are triaged during this meeting and either moved straight to **Ready** or assigned a drafting lane.
|
||||
The product group walks the board **right-to-left**, starting at "Ready for release" and moving back toward "Inbox". Stories in the Inbox are triaged during this meeting and either moved straight to **Ready** or assigned a drafting lane.
|
||||
|
||||
#### Release demo (every 3 weeks)
|
||||
### Release demo (every 3 weeks)
|
||||
|
||||
On the last day of each three-week release cycle, working groups demo shipped changes alongside product groups at the [release demo](#sprint-ceremonies).
|
||||
On the last day of each three-week release cycle, product groups demo shipped changes for the upcoming release alongside stakeholders. Engineers are allotted 3-10 minutes to showcase features, improvements, and bug fixes they contributed. We focus on changes that can be demoed live and avoid overly technical details so the presentation is accessible to everyone. (These meetings are recorded and posted publicly, so participants should avoid mentioning customer names. Instead of a customer name, use a general description like "a publicly-traded hosting company", or the [customer's codename](https://fleetdm.com/handbook/customers#customer-codenames).)
|
||||
|
||||
#### Release retro (30 minutes, every 3 weeks)
|
||||
### Release retro (30 minutes, every 3 weeks)
|
||||
|
||||
At the end of every three-week release cycle, the working group holds a 30-minute retro. Action items are created as [`~timebox`](https://github.com/fleetdm/fleet/labels/~timebox) issues, added to the board, and assigned to the EM for the next release cycle.
|
||||
|
||||
|
||||
### Working group rollout
|
||||
|
||||
The transition to working groups happens over the following release cycles, following a buffer cycle in 4.87.0 to give everyone time to absorb the handbook change before any team changes:
|
||||
|
||||
| Release | Change |
|
||||
|:---|:---|
|
||||
| 4.87.0 | Handbook change published. No team changes this cycle (buffer/ramp-up). |
|
||||
| 4.89.0 | First Impressions pauses. Power to the PC continues with Konstantin Sykulev and Victor Lyuboslavsky, and continues to own Android. |
|
||||
| 4.90.0 | MDM becomes Apple @ Work. Software becomes Auto Patching. |
|
||||
| 4.91.0 | Orchestration product group becomes Digital Employee Experience (DEX). Security & Compliance product group becomes Supply Chain. Both become working groups. |
|
||||
| TBD | BYOD group spins out from Power to the PC to lead Android device management. |
|
||||
|
||||
> When an engineer moves into a new area of the code, allocate one release cycle for ramp-up. Reduced output during that cycle is expected and planned for.
|
||||
At the end of every three-week release cycle, the product group holds a 30-minute retro. Action items are created as [`~timebox`](https://github.com/fleetdm/fleet/labels/~timebox) issues, added to the board, and assigned to the EM for the next release cycle.
|
||||
|
||||
|
||||
### Website group
|
||||
@@ -268,7 +233,7 @@ The goal of the website group is to increase and exceed Fleet's product maturity
|
||||
| Quality Assurance | [Eric Shaw](https://www.linkedin.com/in/eric-shaw-1423831a9/) _([@eashaw](https://github.com/eashaw))_
|
||||
| Software Engineer | [Eric Shaw](https://www.linkedin.com/in/eric-shaw-1423831a9/) _([@eashaw](https://github.com/eashaw))_
|
||||
|
||||
> The [Slack channel](https://fleetdm.slack.com/archives/C097P4TAPRR), [kanban board](https://github.com/orgs/fleetdm/projects/92), and [GitHub label](https://github.com/fleetdm/fleet/labels?q=%23g-website) for this working group is `#g-website`.
|
||||
> The [Slack channel](https://fleetdm.slack.com/archives/C097P4TAPRR), [kanban board](https://github.com/orgs/fleetdm/projects/92), and [GitHub label](https://github.com/fleetdm/fleet/labels?q=%23g-website) for this product group is `#g-website`.
|
||||
|
||||
|
||||
<!--
|
||||
@@ -276,7 +241,7 @@ Paused as of the 4.89.0 release cycle.
|
||||
|
||||
### First Impressions group
|
||||
|
||||
The goal of the First Impressions working group is to make changes to the core Fleet product that improve first impressions of Fleet at workshops, conferences, and demos.
|
||||
The goal of the First Impressions product group is to make changes to the core Fleet product that improve first impressions of Fleet at workshops, conferences, and demos.
|
||||
|
||||
| Responsibility | Human(s) |
|
||||
|:----------------------------------|:--------------------------|
|
||||
@@ -285,29 +250,27 @@ The goal of the First Impressions working group is to make changes to the core F
|
||||
| Quality Assurance | [Andrey Kizimenko](https://www.linkedin.com/in/andrey-kizimenko-988900214/) _([@AndreyKizimenko](https://github.com/AndreyKizimenko))_
|
||||
| Software Engineer | [Luke Heath](https://www.linkedin.com/in/lukeheath/) _([@lukeheath](https://github.com/lukeheath))_
|
||||
|
||||
> The [Slack channel](https://fleetdm.slack.com/archives/C0ACJ8L1FD0), [kanban board](https://github.com/orgs/fleetdm/projects/105/), and [GitHub label](https://github.com/fleetdm/fleet/labels?q=%23g-first-impressions) for this working group is `#g-first-impressions`.
|
||||
> The [Slack channel](https://fleetdm.slack.com/archives/C0ACJ8L1FD0), [kanban board](https://github.com/orgs/fleetdm/projects/105/), and [GitHub label](https://github.com/fleetdm/fleet/labels?q=%23g-first-impressions) for this product group is `#g-first-impressions`.
|
||||
-->
|
||||
|
||||
|
||||
|
||||
### Power to the PC group
|
||||
|
||||
The goal of the Power to the PC working group is to empower Windows users to fully leverage Fleet as an MDM. This group also owns Android device management for the time being, until the BYOD group spins out.
|
||||
The goal of the Power to the PC group is to empower Windows users to fully leverage Fleet as an MDM.
|
||||
|
||||
| Responsibility | Human(s) |
|
||||
|:----------------------------------|:--------------------------|
|
||||
| Product Designer | [Mel Pike](https://www.linkedin.com/in/melpike/) _([@melpike](https://github.com/melpike))_, [Mel Pike](https://www.linkedin.com/in/melpike/) _([@melpike](https://github.com/melpike))_ (Windows), [Noah Talerman](https://www.linkedin.com/in/noah-talerman/) _([@noahtalerman](https://github.com/noahtalerman))_ (Android)
|
||||
| Engineering Manager | [Luke Heath](https://www.linkedin.com/in/lukeheath/) _([@lukeheath](https://github.com/lukeheath))_
|
||||
| Product Designer | [Mel Pike](https://www.linkedin.com/in/melpike/) _([@melpike](https://github.com/melpike))_
|
||||
| Engineering Manager | [Sharon Katz](https://www.linkedin.com/in/sharon-katz-45b1b3a/) _([@sharon-fdm](https://github.com/sharon-fdm))_
|
||||
| Tech Lead | [Victor Lyuboslavsky](https://www.linkedin.com/in/lyuboslavsky/) _([@getvictor](https://github.com/getvictor))_
|
||||
| Quality Assurance | [Joe Grant](https://www.linkedin.com/in/thisisjoegrant/) _([@thisisjoegrant](https://github.com/thisisjoegrant))_
|
||||
| Software Engineer | [Konstantin Sykulev](https://www.linkedin.com/in/konstantins/) _([@ksykulev](https://github.com/ksykulev))_
|
||||
|
||||
> The [Slack channel](https://fleetdm.slack.com/archives/C0AQY8D7FM4), [kanban board](https://github.com/orgs/fleetdm/projects/106/), and [GitHub label](https://github.com/fleetdm/fleet/labels?q=%23g-power-to-pc) for this working group is `#g-power-to-pc`.
|
||||
> The [Slack channel](https://fleetdm.slack.com/archives/C0AQY8D7FM4), [kanban board](https://github.com/orgs/fleetdm/projects/106/), and [GitHub label](https://github.com/fleetdm/fleet/labels?q=%23g-power-to-pc) for this product group is `#g-power-to-pc`.
|
||||
|
||||
|
||||
### Apple @ Work group
|
||||
|
||||
The goal of the Apple @ Work working group is to increase the number of Apple devices managed by Fleet.
|
||||
The goal of the Apple @ Work group is to increase the number of Apple devices managed by Fleet.
|
||||
|
||||
| Responsibility | Human(s) |
|
||||
|:----------------------------------|:--------------------------|
|
||||
@@ -324,12 +287,12 @@ The goal of the Apple @ Work working group is to increase the number of Apple de
|
||||
- Apple setup experience
|
||||
- macOS, iOS, and iPadOS configuration & updates
|
||||
|
||||
> The [Slack channel](https://fleetdm.slack.com/archives/C03C41L5YEL), [kanban board](https://github.com/orgs/fleetdm/projects/58), and [GitHub label](https://github.com/fleetdm/fleet/issues?q=is%3Aopen+is%3Aissue+label%3A%23g-apple-at-work) for this working group is `#g-apple-at-work`.
|
||||
> The [Slack channel](https://fleetdm.slack.com/archives/C03C41L5YEL), [kanban board](https://github.com/orgs/fleetdm/projects/58), and [GitHub label](https://github.com/fleetdm/fleet/issues?q=is%3Aopen+is%3Aissue+label%3A%23g-apple-at-work) for this product group is `#g-apple-at-work`.
|
||||
|
||||
|
||||
### Auto Patching group
|
||||
|
||||
The goal of the Auto Patching working group is to reduce the amount of time before software is patched after vulnerabilities are discovered.
|
||||
The goal of the Auto Patching group is to reduce the amount of time before software is patched after vulnerabilities are discovered.
|
||||
|
||||
| Responsibility | Human(s) |
|
||||
|:----------------------------------|:--------------------------|
|
||||
@@ -348,85 +311,26 @@ The goal of the Auto Patching working group is to reduce the amount of time befo
|
||||
- End user self-service
|
||||
- Scripts
|
||||
|
||||
> The [Slack channel](https://fleetdm.slack.com/archives/C086V2QK76X), [kanban board](https://github.com/orgs/fleetdm/projects/70), and [GitHub label](https://github.com/fleetdm/fleet/labels?q=%23g-auto-patching) for this working group is `#g-auto-patching`.
|
||||
> The [Slack channel](https://fleetdm.slack.com/archives/C086V2QK76X), [kanban board](https://github.com/orgs/fleetdm/projects/70), and [GitHub label](https://github.com/fleetdm/fleet/labels?q=%23g-auto-patching) for this product group is `#g-auto-patching`.
|
||||
|
||||
|
||||
<!--
|
||||
Spin-out date TBD. The BYOD group will spin out from Power to the PC, which owns Android device management in the meantime. See the working group rollout above.
|
||||
|
||||
### BYOD group
|
||||
|
||||
The goal of the BYOD working group is to enable Fleet to manage personally-owned Android devices used at work. This group also owns corporate-owned Android device management so that one team can ensure corporate-owned features are not applied to personal devices.
|
||||
The goal of the BYOD group is to enable Fleet to manage personally-owned Android devices used at work. This group also owns corporate-owned Android device management so that one team can ensure corporate-owned features are not applied to personal devices.
|
||||
|
||||
| Responsibility | Human(s) |
|
||||
|:----------------------------------|:--------------------------|
|
||||
| Product Designer | [LeAnn Gove]([https://www.linkedin.com/in/leann-gove/](https://www.linkedin.com/in/leann-gove-61a750142/)) _([@leanngove](https://github.com/leanngove))_
|
||||
| Engineering Manager | [Luke Heath](https://www.linkedin.com/in/lukeheath/) _([@lukeheath](https://github.com/lukeheath))_
|
||||
| Product Designer | [LeAnn Gove](https://www.linkedin.com/in/leann-gove-61a750142/) _([@leanngove](https://github.com/leanngove))_
|
||||
| Engineering Manager | [George Karr](https://www.linkedin.com/in/george-karr-4977b441/) _([@georgekarrv](https://github.com/georgekarrv))_
|
||||
| Tech Lead | [Konstantin Sykulev](https://www.linkedin.com/in/konstantins/) _([@ksykulev](https://github.com/ksykulev))_
|
||||
| Quality Assurance | [Andrey Kizimenko](https://www.linkedin.com/in/andrey-kizimenko-988900214/) _([@AndreyKizimenko](https://github.com/AndreyKizimenko))_
|
||||
| Software Engineer | Andrew Mellor _([@andymFleet](https://github.com/andymFleet))_
|
||||
|
||||
> Slack channel, kanban board, and GitHub label for this working group: TBD.
|
||||
-->
|
||||
|
||||
|
||||
<!--
|
||||
Planned for the 4.91.0 release cycle. See the working group rollout above. Inherits from the Orchestration product group.
|
||||
|
||||
### Digital Employee Experience (DEX) group
|
||||
|
||||
The goal of the Digital Employee Experience working group is to improve the day-to-day experience of end users by making the devices and tools they rely on at work more reliable, responsive, and easy to use.
|
||||
|
||||
| Responsibility | Human(s) |
|
||||
|:----------------------------------|:--------------------------|
|
||||
| Product Designer | [Rachael Shaw](https://www.linkedin.com/in/rachaelcshaw/) _([@rachaelshaw](https://github.com/rachaelshaw))_
|
||||
| Engineering Manager | [Sharon Katz](https://www.linkedin.com/in/sharon-katz-45b1b3a/) _([@sharon-fdm](https://github.com/sharon-fdm))_
|
||||
| Tech Lead | [Lucas Rodriguez](https://www.linkedin.com/in/lukmr/) _([@lucasmrod](https://github.com/lucasmrod))_
|
||||
| Quality Assurance | [Reed Haynes](https://www.linkedin.com/in/reed-haynes-633a69a3/) _([@xpkoala](https://github.com/xpkoala))_
|
||||
| Software Engineer | [Juan Fernandez](https://www.linkedin.com/in/juan-fdz-hawa/) _([@juan-fdz-hawa](https://github.com/juan-fdz-hawa))_, [Nicolás Ulmete](https://www.linkedin.com/in/nicolasulmete/) _([@nulmete](https://github.com/nulmete))_
|
||||
|
||||
**Areas of expertise**:
|
||||
- Fleetd
|
||||
- Authn / authz
|
||||
- Host data ingestion
|
||||
- Foreign vitals / IdP vitals
|
||||
- Automations
|
||||
- Policies
|
||||
- Queries
|
||||
- Labels
|
||||
- GitOps engine
|
||||
|
||||
> The Slack channel ([TBD]), kanban board ([TBD]), and GitHub label for this working group is `#g-dex`.
|
||||
|
||||
|
||||
### Supply Chain group
|
||||
|
||||
The goal of the Supply Chain working group is to help customers secure the software and dependencies running on their fleet — reducing exposure to vulnerabilities and ensuring compliance across the device lifecycle.
|
||||
|
||||
| Responsibility | Human(s) |
|
||||
|:----------------------------------|:--------------------------|
|
||||
| Product Designer | [Rachael Shaw](https://www.linkedin.com/in/rachaelcshaw/) _([@rachaelshaw](https://github.com/rachaelshaw))_
|
||||
| Engineering Manager | [Sharon Katz](https://www.linkedin.com/in/sharon-katz-45b1b3a/) _([@sharon-fdm](https://github.com/sharon-fdm))_
|
||||
| Tech Lead | [Tim Lee](https://www.linkedin.com/in/mostlikelee/) _([@mostlikelee](https://github.com/mostlikelee))_
|
||||
| Quality Assurance | [Andrey Kizimenko](https://www.linkedin.com/in/andrey-kizimenko-988900214/) _([@AndreyKizimenko](https://github.com/AndreyKizimenko))_
|
||||
| Software Engineer | [Dante Catalfamo](https://www.linkedin.com/in/dante-catalfamo-a6330412b/) _([@dantecatalfamo](https://github.com/dantecatalfamo))_
|
||||
|
||||
**Areas of expertise**:
|
||||
- Software inventory ingestion
|
||||
- CVE/CPE ingestion & matching
|
||||
- Vulnerability reporting
|
||||
- Conditional access
|
||||
- Certificate Authorities (CAs)
|
||||
- Certificate delivery & renewal
|
||||
- Host disk encryption
|
||||
- CIS benchmarks
|
||||
|
||||
> The Slack channel ([TBD]), kanban board ([TBD]), and GitHub label for this working group is `#g-supply-chain`.
|
||||
-->
|
||||
> The [Slack channel](https://fleetdm.slack.com/archives/C0BK050C3BJ), [kanban board](https://github.com/orgs/fleetdm/projects/112), and [GitHub label](https://github.com/fleetdm/fleet/labels?q=%23g-byod) for this product group is `#g-byod`.
|
||||
|
||||
|
||||
<!--
|
||||
Example working group section
|
||||
Example product group section
|
||||
### Name
|
||||
|
||||
Goal
|
||||
@@ -456,13 +360,13 @@ To make a change to Fleet:
|
||||
- Then, it will be [drafted](https://fleetdm.com/handbook/company/product-groups#drafting) (planned).
|
||||
- Next, it will be [implemented](https://fleetdm.com/handbook/company/product-groups#implementing) and [released](https://fleetdm.com/handbook/engineering#release-process).
|
||||
|
||||
Occasionally, a contributor outside of the [product groups](https://fleetdm.com/handbook/product-groups#current-product-groups) (open source contributor, member of the Customer Success team, etc.) will implement a change that was prioritized and drafted. On the user story for these changes, add the product group label (e.g. `#g-apple-at-work`, `#g-orchestration`, `#g-auto-patching`, `#g-security-compliance`), the `:release` label, and notify the product group's Engineering Manager to make sure the changes go through testing (QA) before release.
|
||||
Occasionally, a contributor outside of the [product groups](https://fleetdm.com/handbook/product-groups#current-product-groups) (open source contributor, member of the Customer Success team, etc.) will implement a change that was prioritized and drafted. On the user story for these changes, add the relevant [product group label](https://fleetdm.com/handbook/company/product-groups#current-product-groups), the `:release` label, and notify the product group's Engineering Manager to make sure the changes go through testing (QA) before release.
|
||||
|
||||
When an [open source contributor](https://fleetdm.com/handbook/company#open-source) proposes a change in the form of a pull request (PR), the PR will be [reviewed](https://fleetdm.com/handbook/engineering#review-a-community-pull-request) and then merged or closed.
|
||||
|
||||
### Planned and unplanned changes
|
||||
|
||||
Most changes to Fleet are planned changes. They are [prioritized](https://fleetdm.com/handbook/product), defined, designed, revised, estimated, and scheduled into a release sprint _prior to starting implementation_. The process of going from a prioritized goal to an estimated, scheduled, committed user story with a target release is called "drafting", or "the drafting phase".
|
||||
Most changes to Fleet are planned changes. They are [prioritized](https://fleetdm.com/handbook/product), defined, designed, revised, estimated, and scheduled into a release _prior to starting implementation_. The process of going from a prioritized goal to an estimated, scheduled, committed user story with a target release is called "drafting", or "the drafting phase".
|
||||
|
||||
Occasionally, changes are unplanned. Like a patch for an unexpected bug, or a hotfix for a security issue. Or if an open source contributor suggests an unplanned change in the form of a pull request. These unplanned changes are sometimes OK to merge as-is. But if they change the user interface, the CLI usage, or the REST API, then they need to go through drafting and reconsideration before merging.
|
||||
|
||||
@@ -529,16 +433,14 @@ The DRI for defining and drafting issues for a product group is the product mana
|
||||
|
||||
A user story is considered ready for implementation once:
|
||||
- [ ] User story [issue created](https://github.com/fleetdm/fleet/issues/new/choose)
|
||||
- [ ] [Product group](https://fleetdm.com/handbook/company/product-groups) label added (e.g. `#g-apple-at-work`, `#g-orchestration`, `#g-auto-patching`, `#g-security-compliance`)
|
||||
- [ ] [Product group](https://fleetdm.com/handbook/company/product-groups#current-product-groups) label added
|
||||
- [ ] Changes [specified](https://fleetdm.com/handbook/company/development-groups#drafting) and [designed](https://fleetdm.com/handbook/company/why-this-way#why-do-we-use-a-wireframe-first-approach)
|
||||
- [ ] [Designs revised and settled](#design-reviews)
|
||||
- [ ] Reviewed and approved during [weekly user story review](#user-story-reviews)
|
||||
- [ ] [All checklists are complete](#defining-done)
|
||||
- [ ] [Estimated](https://fleetdm.com/handbook/company/why-this-way#why-scrum)
|
||||
- [ ] [T-shirt sized](#t-shirt-sizing-capacity-planning)
|
||||
- [ ] [Scheduled](https://fleetdm.com/handbook/company/why-this-way#why-a-three-week-cadence) for development
|
||||
|
||||
> All user stories intended for the next sprint are estimated by the last estimation session before the sprint begins. This makes sure contributors have adequate time to complete the current sprint and provide accurate estimates for the next sprint.
|
||||
|
||||
|
||||
#### Writing a good user story
|
||||
|
||||
@@ -552,7 +454,7 @@ Good user stories are short, with clear, unambiguous language.
|
||||
#### Is it actually a story?
|
||||
|
||||
User stories are small and independently valuable.
|
||||
- Is it small enough? Will this task be likely to fit in 1 sprint when estimated?
|
||||
- Is it small enough? Will this task be likely to ship within a single release cycle?
|
||||
- Is it valuable enough? Will this task drive business value when released, independent of other tasks?
|
||||
|
||||
|
||||
@@ -609,16 +511,14 @@ Anyone in the product group can initiate an air guitar session.
|
||||
|
||||
T-shirt sizes represent a rough estimate on the effort required to complete a task for a given team. T-shirt sizes are used to understand the level-of-effort before the task has gone through drafting. That way, we can [plan releases](https://github.com/orgs/fleetdm/projects/87) weeks in advance.
|
||||
|
||||
[Estimation points](https://fleetdm.com/handbook/product-groups#estimation-points) are used if a task has already gone through drafting.
|
||||
|
||||
| T-shirt size | Time | Story points |
|
||||
|:---|:-----------------------------|:-|
|
||||
| XXS | ≤1 day for 1 contributor | 1-3 |
|
||||
| XS | ≤1 week for 1 contributor | 3-8 |
|
||||
| S | ≤1 sprint for 1 contributor | 8-25 |
|
||||
| M | 1 sprint for 2 contributors | 25-50 |
|
||||
| L | 1 sprint for 3 contributors | 50-75 |
|
||||
| XL | >1 sprint for 3 contributors | >75 |
|
||||
| T-shirt size | Time |
|
||||
|:---|:-----------------------------|
|
||||
| XXS | ≤1 day for 1 contributor |
|
||||
| XS | ≤1 week for 1 contributor |
|
||||
| S | ≤1 release cycle for 1 contributor |
|
||||
| M | 1 release cycle for 2 contributors |
|
||||
| L | 1 release cycle for 3 contributors |
|
||||
| XL | >1 release cycle for 3 contributors |
|
||||
|
||||
|
||||
### Implementing
|
||||
@@ -652,7 +552,7 @@ After these considerations, if you still think you've found a blocker, alert the
|
||||
|
||||
The simplest way to manage work is to use a single user story issue, then pass it around between contributors/assignees as seldom as possible. But on a case-by-case basis, for particular user stories and teams, it can sometimes be worthwhile to invest additional overhead in creating separate **unestimated sub-task** issues ("sub-tasks").
|
||||
|
||||
A user story is estimated to fit within 1 sprint and drives business value when released, independent of other stories. Sub-tasks are not.
|
||||
A user story is small enough to ship within a release cycle and drives business value when released, independent of other stories. Sub-tasks are not.
|
||||
|
||||
Sub-tasks:
|
||||
- can be created by anyone
|
||||
@@ -665,22 +565,6 @@ Sub-tasks:
|
||||
- will NOT be looked at or QA'd by quality assurance
|
||||
|
||||
|
||||
### Estimation points
|
||||
|
||||
Estimation points represent the effort required to complete a task. After accessing wireframes, we typically play planning poker, a gamified estimation technique, to determine the necessary story point value. We use the following story points to estimate tasks:
|
||||
|
||||
| Story point | Time |
|
||||
|:---|:--------------|
|
||||
| 1 | 1 to 2 hours |
|
||||
| 2 | 2 to 4 hours |
|
||||
| 3 | 1 day |
|
||||
| 5 | 2 to 3 days |
|
||||
| 8 | Up to a week |
|
||||
| 13 | 1 to 2 weeks |
|
||||
|
||||
> Larger projects are estimated in a way that can sometimes look disproportionate to account for edge cases that weren't caught during planning. This helps us develop [iteratively](https://fleetdm.com/handbook/company#results) and deliver bite-sized functionality on more predictable time scales.
|
||||
|
||||
|
||||
### High-priority user stories and bugs
|
||||
|
||||
All issues are treated as standard priority by default. Some issues are assigned a priority label to indicate the level of urgency.
|
||||
@@ -688,17 +572,17 @@ All issues are treated as standard priority by default. Some issues are assigned
|
||||
- Emergency: `P0`
|
||||
- Examples: Customer outage, inability to modify Fleet configuration, confirmed critical security vulnerability ([critical bug](https://fleetdm.com/handbook/company/product-groups#release-testing)), a new feature is needed to address an immediate Fleet emergency.
|
||||
- Response: Create [incident response issue](https://github.com/fleetdm/confidential/issues/new?template=incident-response.md). Immediately stop other work to swarm the issue. Work 24/7 in shifts until resolved.
|
||||
- Impact: Significant impact. May void current sprint.
|
||||
- Impact: Significant impact. Displaces other in-progress work.
|
||||
|
||||
- Critical: `P1`
|
||||
- Examples: A supported workflow is broken ([critical bug](https://fleetdm.com/handbook/company/product-groups#release-testing)), a potential security vulnerability, a new feature is required to address an immediate critical Fleet need.
|
||||
- Response: Issue brought to next standup for estimation and immediately brought into the sprint. Necessary team members are assigned as their top priority.
|
||||
- Impact: High impact. Does not void sprint, but reduces overall velocity and requires deprioritizing other work.
|
||||
- Response: Issue brought to the next standup and pulled into progress immediately. Necessary team members are assigned as their top priority.
|
||||
- Impact: High impact. Reduces overall throughput and requires deprioritizing other work.
|
||||
|
||||
- Urgent: `P2`
|
||||
- Examples: A supported workflow is not functioning as intended, a newly drafted feature has an associated urgent Fleet need.
|
||||
- Response: Issue is prioritized at the top of the next sprint. If opportunity cost of waiting for the next sprint is too high, it may be considered for current sprint.
|
||||
- Impact: Low to medium impact. If prioritized into current sprint, may reduce overall velocity and require deprioritizing other work.
|
||||
- Response: Issue is prioritized at the top of the group's **Ready** column. If the opportunity cost of waiting is too high, it may be pulled into progress immediately.
|
||||
- Impact: Low to medium impact. May reduce overall throughput and require deprioritizing other work.
|
||||
|
||||
Any fleetie can follow the process below to add a priority label to an issue.
|
||||
|
||||
@@ -751,7 +635,7 @@ All unreleased bugs are addressed before publishing a release. Released bugs tha
|
||||
|
||||
### Notify the community about a critical bug
|
||||
|
||||
We inform customers and the community about critical bugs immediately so they don’t trigger it themselves. When a bug meeting the definition of critical is found, the bug finder is responsible for raising an alarm. Raising an alarm means pinging @here in the `#g-apple-at-work`, `#g-auto-patching`, `#g-orchestration`, or `#g-security-compliance` channel with the filed bug.
|
||||
We inform customers and the community about critical bugs immediately so they don’t trigger it themselves. When a bug meeting the definition of critical is found, the bug finder is responsible for raising an alarm. Raising an alarm means pinging @here in the relevant [product group's](https://fleetdm.com/handbook/company/product-groups#current-product-groups) Slack channel with the filed bug.
|
||||
|
||||
If the bug finder is not a Fleetie (e.g., a member of the community), then whoever sees the critical bug should raise the alarm. Note that the bug finder here is NOT necessarily the **first** person who sees the bug. If you come across a bug you think is critical, but it has not been escalated, raise the alarm!
|
||||
|
||||
@@ -768,7 +652,7 @@ When a critical bug is identified, we will then follow the patch release process
|
||||
|
||||
## Feature fest
|
||||
|
||||
To stay in-sync with our customers' needs, Fleet accepts feature requests from customers and community members on a sprint-by-sprint basis.
|
||||
To stay in-sync with our customers' needs, Fleet accepts feature requests from customers and community members on an ongoing basis.
|
||||
|
||||
Features that meet a [criteria for prioritization](#criteria-for-prioritization) are prioritized at the 🎁🗣 Feature Fest meeting.
|
||||
|
||||
@@ -802,7 +686,7 @@ If an issue has the `:product` and `story` label, then it's a user story that is
|
||||
|
||||
### How feature requests are prioritized
|
||||
|
||||
Prioritization of new feature requests happens at the 🎁🗣 Feature Fest meeting. Before the meeting, during the [🦢📊 Product design sprint review ritual](https://fleetdm.com/handbook/product-design#rituals), the [Feature prioritization DRI](https://fleetdm.com/handbook/company/communications#directly-responsible-individuals-dris) and Product Designers add requests associated with upcoming user stories on Fleet's [release planning project](https://github.com/orgs/fleetdm/projects/87).
|
||||
Prioritization of new feature requests happens at the 🎁🗣 Feature Fest meeting. Before the meeting, during the [🦢📊 Product design review ritual](https://fleetdm.com/handbook/product-design#rituals), the [Feature prioritization DRI](https://fleetdm.com/handbook/company/communications#directly-responsible-individuals-dris) and Product Designers add requests associated with upcoming user stories on Fleet's [release planning project](https://github.com/orgs/fleetdm/projects/87).
|
||||
|
||||
At the **🎁🗣 Feature Fest** meeting, the Feature prioritization DRI weighs all requests in the inbox. When the team weighs a request, it is immediately prioritized or put to the side (not prioritized).
|
||||
|
||||
@@ -811,19 +695,19 @@ At the **🎁🗣 Feature Fest** meeting, the Feature prioritization DRI weighs
|
||||
|
||||
If a feature is not prioritized during a 🎁🗣 Feature Fest meeting, it only means the feature has been rejected _at that time_. Requestors will be notified by the Feature prioritization DRI, and they can add their request back to the feature fest board (`~feature fest` label) to bring it back to a future meeting.
|
||||
|
||||
> If a feature request has an urgent Fleet need and can't wait until the next feature fest, @ mention the Head of Product Design in the `#g-apple-at-work`, `#g-auto-patching`, `#g-orchestration`, or `#g-security-compliance` channel with a link to the request's GitHub issue. It's up to the HPD to decide whether it is immediately prioritized to go through drafting or put to the side. If prioritized, the HPD will decide to de-prioritize one or more feature requests to make room in the current design sprint and notify requesters.
|
||||
> If a feature request has an urgent Fleet need and can't wait until the next feature fest, @ mention the Head of Product Design in the relevant [product group's](https://fleetdm.com/handbook/company/product-groups#current-product-groups) Slack channel with a link to the request's GitHub issue. It's up to the HPD to decide whether it is immediately prioritized to go through drafting or put to the side. If prioritized, the HPD will decide to de-prioritize one or more feature requests to make room in the current design cycle and notify requesters.
|
||||
|
||||
|
||||
### After the feature is accepted
|
||||
|
||||
After the 🎁🗣 Feature fest meeting, the feature prioritization DRI will clear the 🎁 Feature fest board as follows:
|
||||
- Prioritized features: Remove the `~feature fest` label, create one or more user stories with the relevant `customer-` labels (keep the original request as the parent issue), and add stories to the [release planning board](https://github.com/orgs/fleetdm/projects/87). during the "Design sprint kick-off" ritual, the user stories are assigned to a [Product Designer](https://fleetdm.com/handbook/company/product-groups#current-product-groups).
|
||||
- Prioritized features: Remove the `~feature fest` label, create one or more user stories with the relevant `customer-` labels (keep the original request as the parent issue), and add stories to the [release planning board](https://github.com/orgs/fleetdm/projects/87). During the "Design kickoff" ritual, the user stories are assigned to a [Product Designer](https://fleetdm.com/handbook/company/product-groups#current-product-groups).
|
||||
- Put to the side features: Remove `~feature fest` label and notify the requestor.
|
||||
|
||||
> The product team's commitment to the requester is that the prioritized user story will be delivered or the requester will be notified within 1 business day of the decision to de-prioritize the story.
|
||||
|
||||
A story may be de-prioritized when its relative priority falls below new requests and there is not enough room in the upcoming engineering sprint. Since Fleet does not maintain a feature backlog, a story is only prioritized if it seems like it can be shipped in the upcoming 3 week engineering sprint. The relative priority of a story and engineering capacity may change over the course of a design sprint.
|
||||
- This may be because new higher-priority work (bugs or stories) was prioritized and/or the work in the current engineering sprint took longer than expected.
|
||||
A story may be de-prioritized when its relative priority falls below new requests and there is not enough room in an upcoming release. Since Fleet does not maintain a feature backlog, a story is only prioritized if it seems like it can be shipped in the upcoming 3-week release. The relative priority of a story and engineering capacity may change over the course of a design cycle.
|
||||
- This may be because new higher-priority work (bugs or stories) was prioritized and/or the work in the current release took longer than expected.
|
||||
|
||||
Just as when a feature request is not accepted in the 🎁🗣 Feature Fest meeting, whenever a feature is de-prioritized after it has been accepted, it only means that the feature has been _de-prioritized at this time_. It is up to the requester to bring the request back again at another 🎁🗣 Feature Fest meeting.
|
||||
|
||||
@@ -864,8 +748,6 @@ You can read our guide to diagnosing issues in Fleet on the [debugging page](htt
|
||||
|
||||
#### Inbox
|
||||
|
||||
> Working groups use the bug triage process below. For product groups (#g-orchestration and #g-security-compliance) Product Designers are responsible for triaging bugs [as they do today](https://github.com/fleetdm/fleet/blob/dbe9a3434217f2dc934c9af9778541aea60f4fc9/handbook/company/product-groups.md#inbox). Learn more about the [working group rollout](https://fleetdm.com/handbook/company/product-groups#working-group-rollout).
|
||||
|
||||
Quickly confirming and reproducing bug reports is a [priority for Fleet](https://fleetdm.com/handbook/company/why-this-way#why-make-it-obvious-when-stuff-breaks). When a new bug is created using the [bug report template](https://github.com/fleetdm/fleet/issues/new?template=bug-report.md), it is in the "inbox" state. Website bugs (label: `#g-website`) are triaged by the [website group](https://fleetdm.com/handbook/company/product-groups#website-group).
|
||||
|
||||
At this state, the Head of Product Design is responsible for going through the inbox and adding the correct product group label. This moves the bug to the inbox on the product group's board.
|
||||
@@ -908,13 +790,13 @@ If a bug meets the criteria for a [critical bug](https://fleetdm.com/handbook/co
|
||||
|
||||
#### In engineering
|
||||
|
||||
A bug is in engineering after it has gone through product drafting, has received an estimation, and has been moved to a release board during sprint planning.
|
||||
A bug is in engineering after it has gone through product drafting and has been moved to a release board during weekly planning.
|
||||
|
||||
If this is a customer-reported bug that is related to performance at scale, it must be reproduced in a load test environment before a Fleet release can be published containing a fix. Request review of relevant production data to determine what changes are necessary in our load test environment's data set to reproduce the bug. If there is an ongoing outage, a hotfix branch may be deployed without load testing reproduction if approved by the relevant EM.
|
||||
|
||||
#### Awaiting QA
|
||||
|
||||
Bugs will be verified as fixed by QA when they are placed in the "Awaiting QA" column of the relevant product group's sprint board. If the bug is verified as fixed, it is moved to the "Ready for release" column of the sprint board. Otherwise, the remaining issues are noted in a comment, and it is moved back to the "In progress" column of the sprint board.
|
||||
Bugs will be verified as fixed by QA when they are placed in the "Awaiting QA" column of the relevant product group's board. If the bug is verified as fixed, it is moved to the "Ready for release" column of the board. Otherwise, the remaining issues are noted in a comment, and it is moved back to the "In progress" column of the board.
|
||||
|
||||
|
||||
## Engineering on-call
|
||||
@@ -931,7 +813,7 @@ The current on-call rotation is reflected in the [📈 KPIs spreadsheet (confide
|
||||
|
||||
New engineers are added to the on-call rotation by their manager after they have completed onboarding and at least one full release cycle. We aim to alternate the rotation between product groups when possible.
|
||||
|
||||
> The on-call rotation may be adjusted with approval from the EMs of any product groups affected. Any changes should be made before the start of the sprint so that capacity can be planned accordingly.
|
||||
> The on-call rotation may be adjusted with approval from the EMs of any product groups affected. Any changes should be made before the start of the release cycle so that capacity can be planned accordingly.
|
||||
|
||||
#### On-call responsibilities
|
||||
|
||||
@@ -1016,7 +898,7 @@ The Customer Success team member who reports the incident will continue communic
|
||||
|
||||
Each product group maintains two engineers assigned to incident on-call. Engineers in this rotation should be comfortable leading mitigation efforts during a production incident.
|
||||
|
||||
> The incident on-call rotation and handoff are handled automatically by incident.io. The on-call rotation may be adjusted in incident.io with approval from the EMs of any product groups affected. Any changes should be made before the start of the sprint so that capacity can be planned accordingly.
|
||||
> The incident on-call rotation and handoff are handled automatically by incident.io. The on-call rotation may be adjusted in incident.io with approval from the EMs of any product groups affected. Any changes should be made before the start of the release cycle so that capacity can be planned accordingly.
|
||||
|
||||
#### Incident on-call responsibilities
|
||||
|
||||
@@ -1143,9 +1025,9 @@ All participants are expected to review the user story and associated designs an
|
||||
|
||||
Design reviews are conducted daily between the [Head of Product Design](https://fleetdm.com/handbook/product-design#team) (HPD) and contributors (most often Product Designers) proposing changes to Fleet's interfaces, such as the graphical user interface (GUI), REST API or YAML. This fast cadence shortens the feedback loop, makes progress visible, and encourages early feedback. This helps Fleet stay intentional about how the product is designed and minimize common issues like UI inconsistencies or accidental breaking changes to the API. If the HPD can't make it, a Product Designer from a product group attends to give feedback.
|
||||
|
||||
User stories in the current design sprint are always reviewed first during design reviews.
|
||||
User stories in the current design cycle are always reviewed first during design reviews.
|
||||
|
||||
For questions about stories or bugs in the current engineering sprint, start a Slack thread or schedule an ad-hoc meeting.
|
||||
For questions about stories or bugs currently in progress, start a Slack thread or schedule an ad-hoc meeting.
|
||||
|
||||
Anyone at Fleet can attend as a shadow. Shadows are asked to leave feedback/comments in the agenda doc without interrupting the meeting. This helps the team iterate and move designs to ready for spec faster.
|
||||
|
||||
@@ -1208,7 +1090,7 @@ The Account Executive (AE) or Customer Success Manager (CSM) schedules this meet
|
||||
|
||||
If the buyer (aka the "Santa") hasn't reviewed the price in the first order form or we don't have a date attached to the promise(s), then we're not ready for this call.
|
||||
|
||||
On the order form, customer promises are represented as [customer request](https://fleetdm.com/handbook/product-design#unpacking-the-why) issues and not [user stories](https://fleetdm.com/handbook/company/product-groups#scrum-items). CSM's must reserve customer promise requests for issues that are required for a renewal to close or for an expansion to close.
|
||||
On the order form, customer promises are represented as [customer request](https://fleetdm.com/handbook/product-design#unpacking-the-why) issues and not [user stories](https://fleetdm.com/handbook/company/product-groups#work-items). CSM's must reserve customer promise requests for issues that are required for a renewal to close or for an expansion to close.
|
||||
|
||||
**Participants:** AE or CSM, SC, CEO, CTO, VP of Customer Success, Head of Product Design, and relevant EM (+ temporarily: CRO).
|
||||
|
||||
@@ -1243,72 +1125,26 @@ Start off cross-platform for every option, setting, and feature. If we **prove**
|
||||
- **Control the noise.** Bring the needs surface level, tuck away things you don't need by default (when possible, given time). For example, hide Windows controls if there are no Windows devices (based on number of Windows hosts).
|
||||
|
||||
|
||||
## Scrum at Fleet
|
||||
## Work items
|
||||
|
||||
Fleet product groups employ scrum, an agile methodology, as a core practice in software development. This process is designed around sprints, which last three weeks to align with our release cadence.
|
||||
|
||||
New tickets are estimated, specified, and prioritized on the [drafting board](https://github.com/orgs/fleetdm/projects/67).
|
||||
|
||||
|
||||
### Scrum items
|
||||
|
||||
Our scrum boards are exclusively composed of the following types of scrum items:
|
||||
Product group boards are exclusively composed of the following types of work items:
|
||||
|
||||
1. **User stories**: These are simple and concise descriptions of features or requirements from the user's perspective, marked with the `story` label. They keep our focus on delivering value to our customers.
|
||||
|
||||
2. **Sub-tasks**: These smaller, more manageable tasks contribute to the completion of a larger user story. Sub-tasks are labeled as `~sub-task` and enable us to break down complex tasks into more detailed and easier-to-estimate work units. Sub-tasks are always assigned to exactly one user story.
|
||||
|
||||
3. **Timeboxes**: Tasks that are specified to complete within a pre-defined amount of time are marked with the `~timebox` label. Timeboxes are research or investigation tasks necessary to move a prioritized user story forward, sometimes called "spikes" in scrum methodology. We use the term "timebox" because it better communicates its purpose. Timeboxes are always assigned to exactly one user story.
|
||||
3. **Timeboxes**: Tasks that are specified to complete within a pre-defined amount of time are marked with the `~timebox` label. Timeboxes are research or investigation tasks necessary to move a prioritized user story forward, sometimes called "spikes." We use the term "timebox" because it better communicates its purpose. Timeboxes are always assigned to exactly one user story.
|
||||
|
||||
4. **Bugs**: Representing errors or flaws that result in incorrect or unexpected outcomes, bugs are marked with the `bug` label. Like user stories and sub-tasks, bugs are documented, prioritized, and addressed during a sprint.
|
||||
4. **Bugs**: Representing errors or flaws that result in incorrect or unexpected outcomes, bugs are marked with the `bug` label. Like user stories and sub-tasks, bugs are documented, prioritized, and addressed as they move across the board.
|
||||
|
||||
5. **Quick wins**: These are small copy or UX improvements that aren't quite bugs but they're so small that they're worthwhile. Quick wins skip user story review and go straight to the current sprint. It's up to the individual who opened the pull request (PR) to make sure the quick win is moved to "Awaiting QA" when the PR is merged. Like other product changes, quick wins are brought to [design review](https://fleetdm.com/handbook/product-design#rituals). To keep momentum, the PR can be approved and merged before design review.
|
||||
5. **Quick wins**: These are small copy or UX improvements that aren't quite bugs but they're so small that they're worthwhile. Quick wins skip user story review and go straight to **Ready**. It's up to the individual who opened the pull request (PR) to make sure the quick win is moved to "Awaiting QA" when the PR is merged. Like other product changes, quick wins are brought to [design review](https://fleetdm.com/handbook/product-design#rituals). To keep momentum, the PR can be approved and merged before design review.
|
||||
|
||||
6. **Reliability issues**: These represent scaling, performance, or reliability concerns, including post-mortem action items, marked with the `reliability` label. Reliability issues are prioritized by severity by both product and engineering. They are used to track work that improves system stability, addresses incident follow-ups, and resolves operational risks.
|
||||
|
||||
> Our sprint boards do not accommodate any other type of ticket. By strictly adhering to these scrum items, we maintain an organized and focused workflow that consistently adds value for our users.
|
||||
> Product group boards do not accommodate any other type of ticket. By strictly adhering to these work items, we maintain an organized and focused workflow that consistently adds value for our users.
|
||||
|
||||
|
||||
## Sprints
|
||||
|
||||
Sprints align with Fleet's [3-week release cycle](https://fleetdm.com/handbook/company/why-this-way#why-a-three-week-cadence).
|
||||
|
||||
On the first day of each release, all estimated issues are moved into the relevant section of the new "Release" board, which has a kanban view per group.
|
||||
|
||||
Sprints are managed in [GitHub Projects](https://fleetdm.com/handbook/company/why-this-way#why-make-work-visible).
|
||||
|
||||
|
||||
### Sprint numbering
|
||||
|
||||
Sprints are numbered according to the release version. For example, for the sprint ending on June 30th, 2023, on which date we expect to release Fleet v4.34, the sprint is called the 4.34 sprint.
|
||||
|
||||
|
||||
### Sprint ceremonies
|
||||
|
||||
See the [rituals contributor docs](https://github.com/fleetdm/fleet/tree/main/docs/Contributing/rituals) for detailed instructions on running each ceremony.
|
||||
|
||||
Each release cycle is marked by five essential ceremonies:
|
||||
|
||||
1. **Sprint kickoff**: On the first day of the sprint, the team, along with stakeholders, selects issues from the [🦢 Drafting board](https://github.com/orgs/fleetdm/projects/67) to work on. To move issues to the sprint board, add `:release` and the product group label (`#g-apple-at-work`, `#g-orchestration`, `#g-auto-patching`, `#g-security-compliance`) and remove the 🦢 Drafting project. The team then commits to completing these items within the sprint.
|
||||
2. **Daily standup**: Every day, the team convenes for updates. During this session, each team member shares what they accomplished since the last standup, their plans until the next meeting, and any blockers they are experiencing. The team briefly reviews the [bug Inbox](https://github.com/fleetdm/fleet/issues?q=is%3Aopen+is%3Aissue+label%3Abug+label%3A%3Areproduce) to identify any bugs ready to move forward or that need a QA engineer assigned, the goal is that these bugs are timeboxed for 30m-1hr to reproduce or ask for additional details. Standups should last no longer than fifteen minutes. If additional discussion is necessary, it takes place after the standup with only the required participants.
|
||||
3. **Weekly estimation sessions**: The team estimates backlog items once a week (three times per sprint). These sessions help to schedule work completion and align the roadmap with business needs. They also provide estimated work units for upcoming sprints. The EM is responsible for the point values assigned to each item and ensures they are as realistic as possible.
|
||||
4. **Scrum of scrums**: Each product group's Tech Lead, and optionally the EMs, meet once per sprint. This is a coordination technique used to scale scrum for multiple teams working on a large, complex product by having representatives from each team meet regularly to share progress, discuss dependencies, and solve inter-team issues.
|
||||
5. **Release demo**: On the last day of each release cycle, product groups and working groups demo shipped changes for the upcoming release alongside stakeholders. Engineers are allotted 3-10 minutes to showcase features, improvements, and bug fixes they have contributed to the upcoming release. We focus on changes that can be demoed live and avoid overly technical details so the presentation is accessible to everyone. Features should show what is capable and bugs should identify how this might have impacted existing customers and how this resolution fixed that. (These meetings are recorded and posted publicly to YouTube or other platforms, so participants should avoid mentioning customer names. For example, instead of "Fastly", you can say "a publicly-traded hosting company", or use the [customer's codename](https://fleetdm.com/handbook/customers#customer-codenames).)
|
||||
6. **Sprint retrospective**: Also held on the last day of the sprint, this meeting encourages discussions among the team and stakeholders around three key areas: what went well, what could have been better, and what the team learned during the sprint.
|
||||
|
||||
|
||||
### Working through the sprint
|
||||
|
||||
At sprint kickoff, the EM or TL may assign planned issues to specific contributors. Other planned sprint work may remain unassigned until a contributor is ready to pick it up.
|
||||
|
||||
1. **Aim for one issue in progress at a time.** When possible, complete the current task before starting another. Do not self-assign issues until you are ready to work on them.
|
||||
2. **Pick up unassigned sprint work as tasks complete.** When an issue moves to the next stage (e.g., ready for QA), if you have no other planned issues assigned to you, select the next unassigned item from the sprint board.
|
||||
3. **Help finish sprint work when all planned items are assigned.** If no unassigned sprint work remains:
|
||||
- Assist with engineering QA for in-flight issues.
|
||||
- Help complete sub-issues for active user stories.
|
||||
4. **Look ahead when sprint work is done.** If all sprint work is complete or blocked, check the team's drafting board for issues in the "Estimated" column. Prioritize unreleased bugs over released bugs.
|
||||
|
||||
#### Bug prioritization
|
||||
## Bug prioritization
|
||||
|
||||
When selecting which bug to work on next, prioritize in the following order:
|
||||
|
||||
@@ -1336,6 +1172,36 @@ Please see [handbook/company/product-groups/orchestration](https://fleetdm.com/h
|
||||
##### Air guitar
|
||||
Please see [handbook/company/initiate-an-air-guitar-session](https://fleetdm.com/handbook/company/product-groups#initiate-an-air-guitar-session)
|
||||
|
||||
##### Security & compliance group
|
||||
Please see [handbook/company/product-groups#supply-chain-group](https://fleetdm.com/handbook/company/product-groups#supply-chain-group)
|
||||
|
||||
##### Working groups
|
||||
Please see [handbook/company/product-groups#continuous-flow](https://fleetdm.com/handbook/company/product-groups#continuous-flow)
|
||||
|
||||
##### Working group rollout
|
||||
Please see [handbook/company/product-groups#current-product-groups](https://fleetdm.com/handbook/company/product-groups#current-product-groups)
|
||||
|
||||
##### Scrum at Fleet
|
||||
Please see [handbook/company/product-groups#continuous-flow](https://fleetdm.com/handbook/company/product-groups#continuous-flow)
|
||||
|
||||
##### Scrum items
|
||||
Please see [handbook/company/product-groups#work-items](https://fleetdm.com/handbook/company/product-groups#work-items)
|
||||
|
||||
##### Sprints
|
||||
Please see [handbook/company/product-groups#continuous-flow](https://fleetdm.com/handbook/company/product-groups#continuous-flow)
|
||||
|
||||
##### Sprint numbering
|
||||
Please see [handbook/company/product-groups#continuous-flow](https://fleetdm.com/handbook/company/product-groups#continuous-flow)
|
||||
|
||||
##### Sprint ceremonies
|
||||
Please see [handbook/company/product-groups#continuous-flow](https://fleetdm.com/handbook/company/product-groups#continuous-flow)
|
||||
|
||||
##### Working through the sprint
|
||||
Please see [handbook/company/product-groups#working-the-board](https://fleetdm.com/handbook/company/product-groups#working-the-board)
|
||||
|
||||
##### Estimation points
|
||||
Please see [handbook/company/product-groups#t-shirt-sizing-capacity-planning](https://fleetdm.com/handbook/company/product-groups#t-shirt-sizing-capacity-planning)
|
||||
|
||||
|
||||
<meta name="maintainedBy" value="lukeheath">
|
||||
<meta name="title" value="🛩️ Product groups">
|
||||
|
||||
@@ -231,14 +231,14 @@ We apply the [twelve principles of agile](https://agilemanifesto.org) to Fleet's
|
||||
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
|
||||
|
||||
|
||||
### Why scrum?
|
||||
### Why continuous flow?
|
||||
|
||||
Scrum is an agile framework for software development that helps teams deliver high quality software faster. It emphasizes teamwork, collaboration, and continuous improvement to achieve business objectives. Here are some of the key reasons why [we use scrum at Fleet](https://fleetdm.com/handbook/engineering#scrum)):
|
||||
- Improved collaboration and communication: Scrum emphasizes teamwork and collaboration, which leads to better communication between team members and stakeholders. This helps ensure that everyone is aligned and working towards the same goals.
|
||||
- Flexibility and adaptability: Scrum allows teams to respond quickly to changing requirements and market conditions. By working in short sprints, teams can continuously adapt to new information and feedback, and adjust their approach as needed.
|
||||
- Continuous improvement: Scrum encourages teams to reflect on their processes and identify areas for improvement. The regular sprint retrospective meetings provide a forum for the team to discuss what went well and what could be improved, and to make changes to their processes accordingly.
|
||||
- Faster delivery of working software: Scrum helps teams deliver working software faster by breaking down the development process into manageable chunks that can be completed within a sprint. Stakeholders can see progress and provide feedback more quickly, which helps ensure the final product meets their needs.
|
||||
- Higher quality software: Scrum includes regular testing and quality assurance activities, which help ensure that the software being developed is of high quality and meets the required standards.
|
||||
Fleet's product groups use a continuous flow process instead of fixed multi-week iterations. Well-drafted stories can often be implemented in a day or two, so batching work into fixed iterations adds latency without adding value. Instead, issues flow continuously across each group's board from intake to release. Here are some of the reasons we work [this way](https://fleetdm.com/handbook/company/product-groups#continuous-flow):
|
||||
- Less latency: Work starts as soon as it is ready, instead of waiting for the next iteration to begin.
|
||||
- Flexibility and adaptability: Teams respond quickly to changing requirements and new information, and adjust their approach as they learn.
|
||||
- Continuous improvement: A short retrospective at the end of each three-week release gives the team a regular forum to reflect on what went well, what could be better, and what to change.
|
||||
- Faster delivery of working software: Breaking work into small, independently valuable stories lets the team ship and gather feedback sooner.
|
||||
- Higher quality software: Quality assurance is involved from intake onward, so testing and reliability are built in rather than bolted on.
|
||||
|
||||
|
||||
### Why lean software development?
|
||||
@@ -512,5 +512,8 @@ Please see [handbook/company/why-this-way#why-direct-responsibility](https://fle
|
||||
##### What is a P1?
|
||||
Please see [handbook/company/why-this-way#why-spend-so-much-energy-responding-to-every-potential-production-incident](https://fleetdm.com/handbook/company/why-this-way#why-spend-so-much-energy-responding-to-every-potential-production-incident).
|
||||
|
||||
##### Why scrum?
|
||||
Please see [handbook/company/why-this-way#why-continuous-flow](https://fleetdm.com/handbook/company/why-this-way#why-continuous-flow).
|
||||
|
||||
<meta name="maintainedBy" value="mikermcneil">
|
||||
<meta name="title" value="💭 Why this way?">
|
||||
|
||||
@@ -167,7 +167,7 @@ Business reviews are conducted quarterly or bi-annually to ensure initial succes
|
||||
- Have a support engineer collect data on open and closed bugs from the previous quarter and highlight any P0 or P1 incidents along with a summary of the postmortem (search Unthread and GitHub for issues tagged with the customer codename and ':bug').
|
||||
- Summarize status updates for open feature requests and highlight delivered feature requests.
|
||||
- For managed cloud customers, reach out to #help-infrastructure to collect information on cloud uptime and any outages or alarms.
|
||||
- Provide one slide with information on the latest Fleet release and any upcoming big ticket features which can be found on the product board and current release board for any product or working group.
|
||||
- Provide one slide with information on the latest Fleet release and any upcoming big ticket features which can be found on the product board and current release board for any product or product group.
|
||||
3. After the business review, save the presentation as a PDF and share it with your customer.
|
||||
|
||||
### Track a customer promise
|
||||
@@ -588,7 +588,7 @@ Once you submit the form, Stripe will refund the user's payment and cancel their
|
||||
When a user requests that we delete all data we have stored about them, their data will need to be removed from the following places:
|
||||
1. **fleetdm.com**
|
||||
- Create a confidential website request issue
|
||||
- If the user signed up for an account on fleetdm.com, you will need to create a confidential website request issue. A member of the #g-website working group will delete the account and let you know in a comment when the user account is deleted.
|
||||
- If the user signed up for an account on fleetdm.com, you will need to create a confidential website request issue. A member of the #g-website product group will delete the account and let you know in a comment when the user account is deleted.
|
||||
2. **Salesforce**
|
||||
1. Search Salesforce for the user's email address, delete the contact record, and any related historical event records associated with the user's contact record.
|
||||
3. **Stripe**
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
- task: "Prioritize for next sprint" # Title that will actually show in rituals table
|
||||
- task: "Prioritize for next release cycle" # Title that will actually show in rituals table
|
||||
startedOn: "2023-09-04" # Needs to align with frequency e.g. if frequency is every thrid Thursday startedOn === any third thursday
|
||||
frequency: "Triweekly" # must be supported by
|
||||
description: "Using your departmental kanban board, prioritize and finalize next sprint's goals for your team by draging the appropriate issues to the top of the 'Not yet' column." # example of a longer thing: description: "[Prioritizing next sprint](https://fleetdm.com/handbook/company/communication)"
|
||||
description: "Using your departmental kanban board, prioritize and finalize next release cycle's goals for your team by draging the appropriate issues to the top of the 'Not yet' column." # example of a longer thing: description: "[Prioritizing next release cycle](https://fleetdm.com/handbook/company/communication)"
|
||||
moreInfoUrl: "https://fleetdm.com/handbook/company/why-this-way#why-make-work-visible" #URL used to highlight "description:" test in table
|
||||
dri: "zayhanlon" # DRI for ritual (assignee if autoIssue) (TODO display GitHub proflie pic instead of name or title)
|
||||
autoIssue: # Enables automation of GitHub issues
|
||||
|
||||
@@ -66,7 +66,7 @@ The engineering output and architecture DRI reviews and triages engineering-init
|
||||
|
||||
1. The assigned engineer is responsible for completing the user story drafting process by completing the specs and [defining done](https://fleetdm.com/handbook/company/product-groups#defining-done). Move the issue into "In progress" on the drafting board and populate all TODOs in the issue description, define implementation details, and draft the first version of the test plan.
|
||||
|
||||
2. When all sections have been populated, move it to the "User story review" column on the drafting board and assign to your EM. The EM will bring the story to [weekly user story review](https://fleetdm.com/handbook/company/product-groups#user-story-reviews), and then to estimation before prioritizing into an upcoming sprint.
|
||||
2. When all sections have been populated, move it to the "User story review" column on the drafting board and assign to your EM. The EM will bring the story to [weekly user story review](https://fleetdm.com/handbook/company/product-groups#user-story-reviews), and then to estimation before prioritizing into an upcoming release.
|
||||
|
||||
> We prefer the term engineering-initiated stories over technical debt because the user story format helps keep us focused on our users and contributors.
|
||||
|
||||
@@ -114,14 +114,14 @@ All conversation about an unfixed vulnerability stays in the confidential repo
|
||||
|
||||
#### Notify stakeholders when a user story is pushed to the next release
|
||||
|
||||
[User stories](https://fleetdm.com/handbook/company/product-groups#scrum-items) are intended to be completed in a single sprint. When the Tech Lead knows a user story will be pushed, it is the product group Tech Lead's responsibility to notify stakeholders:
|
||||
[User stories](https://fleetdm.com/handbook/company/product-groups#work-items) are intended to be completed in a single release cycle. When the Tech Lead knows a user story will be pushed, it is the product group Tech Lead's responsibility to notify stakeholders:
|
||||
|
||||
1. Add the `~pushed` label to the user story.
|
||||
2. Update the user story's milestone to the next minor version milestone.
|
||||
3. Comment on the GitHub issue and at-mention the Head of Product Design, the product group's Engineering Manager, and anyone listed in the requester field.
|
||||
4. If `customer-` labels are applied to the user story, at-mention the [VP of Customer Success](https://fleetdm.com/handbook/customer-success#team) in the #g-apple-at-work, #g-auto-patching, #g-orchestration, or #g-security-compliance Slack channel.
|
||||
4. If `customer-` labels are applied to the user story, at-mention the [VP of Customer Success](https://fleetdm.com/handbook/customer-success#team) in the relevant [product group's](https://fleetdm.com/handbook/company/product-groups#current-product-groups) Slack channel.
|
||||
|
||||
> Instead of waiting until the end of the sprint, notify stakeholders as soon as you know the story is being pushed.
|
||||
> Instead of waiting until the end of the release cycle, notify stakeholders as soon as you know the story is being pushed.
|
||||
|
||||
|
||||
### Community contributions
|
||||
@@ -144,7 +144,7 @@ Make sure to create a Github issue and link it to the PR so that we can track th
|
||||
The PD will be the contact point for the contributor and will ensure the PR is reviewed by the appropriate team member when ready. The PD should:
|
||||
|
||||
- Set the PR to draft.
|
||||
- Immediately decide whether to prioritize a [user story or quick win](https://fleetdm.com/handbook/company/product-groups#scrum-items) and bring it through drafting or put the change to the side (not prioritize).
|
||||
- Immediately decide whether to prioritize a [user story or quick win](https://fleetdm.com/handbook/company/product-groups#work-items) and bring it through drafting or put the change to the side (not prioritize).
|
||||
- Thank the contributor for their hard work, notify them on whether their change was prioritized or put to the side. If the change was put to the side, ask the contributor to file a [feature request](https://github.com/fleetdm/fleet/issues/new?assignees=&labels=%3Aproduct&projects=&template=feature-request.md&title=) that describes the change, let them know that it only means the change has been rejected _at that time_, and close the PR.
|
||||
|
||||
|
||||
@@ -218,7 +218,7 @@ Because remote-triggered sessions run as you, on your machine, take the followin
|
||||
|
||||
#### On-call engineer
|
||||
|
||||
Engineering Managers are asked to be aware of the [on-call engineer rotations](https://fleetdm.com/handbook/company/product-groups#on-call-engineer) and reduce estimated capacity for each sprint accordingly. While it varies week to week considerably, the on-call responsibilities can sometimes take up a substantial portion of the engineer's time.
|
||||
Engineering Managers are asked to be aware of the [on-call engineer rotations](https://fleetdm.com/handbook/company/product-groups#on-call-engineer) and reduce estimated capacity for each release cycle accordingly. While it varies week to week considerably, the on-call responsibilities can sometimes take up a substantial portion of the engineer's time.
|
||||
|
||||
On-call engineers are available during the business hours of 9am - 5pm Central. The [on-call support SLA](https://fleetdm.com/handbook/company/product-groups#on-call-responsibilities) requires a 1-hour response time during business hours to any `@oncall` mention.
|
||||
|
||||
@@ -229,12 +229,12 @@ The on-call engineer is responsible for:
|
||||
- [Escalating community questions and issues](https://fleetdm.com/handbook/company/product-groups#escalations).
|
||||
- Successfully [transferring the on-call persona to the next engineer](https://fleetdm.com/handbook/company/product-groups#changing-of-the-guard).
|
||||
|
||||
To provide full-time focus to the role, the on-call engineer is not expected to work on sprint issues during their on-call assignment.
|
||||
To provide full-time focus to the role, the on-call engineer is not expected to work on release issues during their on-call assignment.
|
||||
|
||||
|
||||
#### Incident on-call engineer
|
||||
|
||||
Engineering Managers are asked to be aware of the [incident on-call engineer rotations](https://fleetdm.com/handbook/company/product-groups#incident-on-call-engineer) and plan estimated capacity for each sprint accordingly. While there are no incidents most weeks, when they occur the incident on-call responsibilities can sometimes take up a substantial portion of the engineer's time. A full sprint's capacity should be planned for the engineer, but one week of capacity should be non-urgent issues that can be delayed to the next sprint if necessary.
|
||||
Engineering Managers are asked to be aware of the [incident on-call engineer rotations](https://fleetdm.com/handbook/company/product-groups#incident-on-call-engineer) and plan estimated capacity for each release cycle accordingly. While there are no incidents most weeks, when they occur the incident on-call responsibilities can sometimes take up a substantial portion of the engineer's time. A full release cycle's capacity should be planned for the engineer, but one week of capacity should be non-urgent issues that can be delayed to the next release cycle if necessary.
|
||||
|
||||
Incident on-call engineers are available 24/7 during their one-week shift. They respond only to P0 issues that have an [incident response issue](https://github.com/fleetdm/confidential/issues/new?template=incident-response.md) filed. Notifications are sent via incident.io, triggered by creating an incident response issue.
|
||||
|
||||
|
||||
@@ -109,14 +109,14 @@
|
||||
task: "Release QA"
|
||||
startedOn: "2023-08-09"
|
||||
frequency: "Triweekly"
|
||||
description: "Every release cycle, by end of day Friday of release week, move all issues to the ”✅ Ready for release” column on the #g-apple-at-work and #g-endpoint-ops sprint boards."
|
||||
description: "Every release cycle, by end of day Friday of release week, move all issues to the ”✅ Ready for release” column on the #g-apple-at-work and #g-endpoint-ops release boards."
|
||||
moreInfoUrl:
|
||||
dri: "AndreyKizimenko"
|
||||
-
|
||||
task: "Submit test coverage requests to QA Wolf"
|
||||
startedOn: "2025-07-29"
|
||||
frequency: "Triweekly"
|
||||
description: "After each sprint, review merged work and submit automation candidates to QA Wolf using the coverage request form."
|
||||
description: "After each release cycle, review merged work and submit automation candidates to QA Wolf using the coverage request form."
|
||||
moreInfoUrl: "https://fleetdm.com/handbook/engineering/releases#submit-test-coverage-requests-to-qa-wolf"
|
||||
dri: "AndreyKizimenko"
|
||||
-
|
||||
@@ -167,16 +167,16 @@
|
||||
moreInfoUrl: "https://fleetdm.com/handbook/engineering/website#change-the-integrations-admin-salesforce-account-password"
|
||||
dri: "eashaw"
|
||||
-
|
||||
task: "Pre-sprint prioritization"
|
||||
task: "Pre-release prioritization"
|
||||
startedOn: "2024-02-27"
|
||||
frequency: "Triweekly"
|
||||
description: "Decide which stories and bugs to bring in to the upcoming sprint. Ahead of the call, Engineering Managers (EM) for each product group prepare their team's estimated capacity that factors in time off (PTO) and the on-call rotation."
|
||||
description: "Decide which stories and bugs to bring in to the upcoming release. Ahead of the call, Engineering Managers (EM) for each product group prepare their team's estimated capacity that factors in time off (PTO) and the on-call rotation."
|
||||
dri: "lukeheath"
|
||||
-
|
||||
task: "Sprint kickoff review"
|
||||
task: "Release kickoff review"
|
||||
startedOn: "2024-03-07"
|
||||
frequency: "Triweekly"
|
||||
description: "Review stories that made it into this sprint and stories that didn't make it into this sprint. Ensure stories/bugs have been effectively prioritized across teams."
|
||||
description: "Review stories that made it into this release and stories that didn't make it into this release. Ensure stories/bugs have been effectively prioritized across teams."
|
||||
moreInfoUrl:
|
||||
dri: "lukeheath"
|
||||
-
|
||||
|
||||
@@ -5,7 +5,7 @@ This handbook page details Fleet's release process, including QA, release candid
|
||||
|
||||
## Participate in QA Day
|
||||
|
||||
Once per sprint, each product group is expected to take a day to assist in QA-related activities. On that day, generally the most straightforward way to assist the QA team is to validate issues in the `Awaiting QA` stage marked with the `~assisting-qa` label. Start with issues milestoned for the lowest-version-number active release candidate, and clear your product group's queue for that release before assisting another team with QA. You may not QA issues where you made code changes, to ensure that two people run through the test plan (the implementing engineer and the person performing QA).
|
||||
Once per release cycle, each product group is expected to take a day to assist in QA-related activities. On that day, generally the most straightforward way to assist the QA team is to validate issues in the `Awaiting QA` stage marked with the `~assisting-qa` label. Start with issues milestoned for the lowest-version-number active release candidate, and clear your product group's queue for that release before assisting another team with QA. You may not QA issues where you made code changes, to ensure that two people run through the test plan (the implementing engineer and the person performing QA).
|
||||
|
||||
For each issue:
|
||||
|
||||
@@ -26,14 +26,14 @@ To start a preview without starting the simulated hosts, use the `--no-hosts` fl
|
||||
|
||||
For each bug found, please use the [bug report template](https://github.com/fleetdm/fleet/issues/new?assignees=&labels=bug%2C%3Areproduce&template=bug-report.md&title=) to create a new bug report issue.
|
||||
|
||||
For unreleased bugs in an active sprint, a new bug is created with the `~unreleased bug` label. The `:release` label and associated product group label is added, and the milestone is set to the version that the feature will be released in. For example, if the feature will be released in v4.71.0 and the bug did not exist prior to that version, the milestone is set to `v4.71.0`. The engineer responsible for the feature is assigned. If QA is unsure who the bug should be assigned to, it is assigned to the EM. Fixing the bug becomes part of the story.
|
||||
For unreleased bugs in an active release, a new bug is created with the `~unreleased bug` label. The `:release` label and associated product group label is added, and the milestone is set to the version that the feature will be released in. For example, if the feature will be released in v4.71.0 and the bug did not exist prior to that version, the milestone is set to `v4.71.0`. The engineer responsible for the feature is assigned. If QA is unsure who the bug should be assigned to, it is assigned to the EM. Fixing the bug becomes part of the story.
|
||||
|
||||
|
||||
## Create a release candidate
|
||||
|
||||
All minor releases go through the release candidate process before they are published. A release candidate for the next minor release is created on the first Monday of the next sprint at 8:00 AM Pacific (see [Fleet's release calendar](https://calendar.google.com/calendar/u/0?cid=Y192Nzk0M2RlcW4xdW5zNDg4YTY1djJkOTRic0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t)). A release candidate branch is created at `rc-minor-fleet-v4.x.x` and no additional feature work or released bug fixes are merged without EM and QA approval.
|
||||
All minor releases go through the release candidate process before they are published. A release candidate for the next minor release is created on the first Monday of the next release cycle at 8:00 AM Pacific (see [Fleet's release calendar](https://calendar.google.com/calendar/u/0?cid=Y192Nzk0M2RlcW4xdW5zNDg4YTY1djJkOTRic0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t)). A release candidate branch is created at `rc-minor-fleet-v4.x.x` and no additional feature work or released bug fixes are merged without EM and QA approval.
|
||||
|
||||
1. [Run the first step](https://github.com/fleetdm/fleet/tree/main/tools/release#minor-release-typically-end-of-sprint) of the minor release section of the Fleet releases script to create the release candidate branch, the release QA issue, and announce the release candidate in Slack.
|
||||
1. [Run the first step](https://github.com/fleetdm/fleet/tree/main/tools/release#minor-release) of the minor release section of the Fleet releases script to create the release candidate branch, the release QA issue, and announce the release candidate in Slack.
|
||||
|
||||
2. Open the [confidential repo environment variables](https://github.com/fleetdm/confidential/settings/variables/actions) page and update the `QAWOLF_DEPLOY_TAG` repository variable with the name of the release candidate branch.
|
||||
|
||||
@@ -71,7 +71,7 @@ Before kicking off release QA, confirm that we are using the latest versions of
|
||||
- Check the [Go version specified in Fleet's go.mod file](https://github.com/fleetdm/fleet/blob/main/go.mod) (`go 1.XX.YY`).
|
||||
- Check the [latest minor version of Go](https://go.dev/dl/). For example, if we are using `go1.19.8`, and there is a new minor version `go1.19.9`, we will upgrade.
|
||||
- If the latest minor version is greater than the version included in Fleet, [file a bug](https://github.com/fleetdm/fleet/issues/new?assignees=&labels=bug%2C%3Areproduce&projects=&template=bug-report.md&title=) and assign it to the [release ritual DRI](https://fleetdm.com/handbook/engineering#rituals) and the current oncall engineer. Add the `~release blocker` label. We must upgrade to the latest minor version before publishing the next release.
|
||||
- If the latest major version is greater than the version included in Fleet, [create a story](https://github.com/fleetdm/fleet/issues/new?assignees=&labels=story%2C%3Aproduct&projects=&template=story.md&title=) and assign it to the [release ritual DRI](https://fleetdm.com/handbook/engineering#rituals) and the current oncall engineer. This will be considered for an upcoming sprint. The release can proceed without upgrading the major version.
|
||||
- If the latest major version is greater than the version included in Fleet, [create a story](https://github.com/fleetdm/fleet/issues/new?assignees=&labels=story%2C%3Aproduct&projects=&template=story.md&title=) and assign it to the [release ritual DRI](https://fleetdm.com/handbook/engineering#rituals) and the current oncall engineer. This will be considered for an upcoming release. The release can proceed without upgrading the major version.
|
||||
|
||||
> In Go versioning, the number after the first dot is the "major" version, while the number after the second dot is the "minor" version. For example, in Go 1.19.9, "19" is the major version and "9" is the minor version. Major version upgrades are assessed separately by engineering.
|
||||
|
||||
@@ -104,12 +104,12 @@ Once a product group completes its QA process during the release candidate perio
|
||||
|
||||
## Submit test coverage requests to QA Wolf
|
||||
|
||||
Fleet QA owns the test planning process and identifies what needs to be automated. After each sprint, we review merged PRs, release notes, and demo recordings to find new automation candidates.
|
||||
Fleet QA owns the test planning process and identifies what needs to be automated. After each release, we review merged PRs, release notes, and demo recordings to find new automation candidates.
|
||||
We track these in a shared [Google Doc](https://docs.google.com/document/d/1jr8wxZZNTvcAB2IMOrsqY4NTW4eceX-3CABiYKpb_pY/edit?usp=sharing) and categorize them as:
|
||||
- New test requests (feature + what to test)
|
||||
- Existing tests to update
|
||||
|
||||
Once coverage is agreed on, Fleet QA submits the request via [QA Wolf's Coverage Request form](https://app.qawolf.com/fleet/coverage-requests). The most recent sprints are prioritized first.
|
||||
Once coverage is agreed on, Fleet QA submits the request via [QA Wolf's Coverage Request form](https://app.qawolf.com/fleet/coverage-requests). The most recent releases are prioritized first.
|
||||
This workflow lets QA Wolf focus on test implementation while Fleet QA stays accountable for identifying clear, high-value test needs.
|
||||
|
||||
|
||||
|
||||
@@ -25,16 +25,16 @@
|
||||
- task: "Key review prep"
|
||||
startedOn: "2024-02-14"
|
||||
frequency: "Triweekly"
|
||||
description: "Prepare for this sprint's Key review meeting."
|
||||
description: "Prepare for this release cycle's Key review meeting."
|
||||
moreInfoUrl: "https://fleetdm.com/handbook/company/leadership#key-reviews"
|
||||
dri: "rfoo2015"
|
||||
autoIssue:
|
||||
labels: [":help-finance"]
|
||||
repo: "confidential"
|
||||
- task: "Prioritize for next sprint" # Title that will actually show in rituals table
|
||||
- task: "Prioritize for next release cycle" # Title that will actually show in rituals table
|
||||
startedOn: "2023-08-09" # Needs to align with frequency e.g. if frequency is every thrid Thursday startedOn === any third thursday
|
||||
frequency: "Triweekly" # must be supported by https://github.com/fleetdm/fleet/blob/dbbb501358e226fa3fdf48865175efe3334c826c/website/scripts/build-static-content.js
|
||||
description: "Using your departmental kanban board, prioritize and finalize next sprint's goals for your team by draging the appropriate issues to the top of the 'Not yet' column." # example of a longer thing
|
||||
description: "Using your departmental kanban board, prioritize and finalize next release cycle's goals for your team by draging the appropriate issues to the top of the 'Not yet' column." # example of a longer thing
|
||||
moreInfoUrl: "https://fleetdm.com/handbook/company/why-this-way#why-make-work-visible" #URL used to highlight "description:" test in table
|
||||
dri: "rfoo2015" # DRI for ritual (assignee if autoIssue) (TODO display GitHub proflie pic instead of name or title)
|
||||
autoIssue: # Enables automation of GitHub issues
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# https://github.com/fleetdm/fleet/pull/13084
|
||||
- task: "Prioritize for next sprint" # Title that will actually show in rituals table
|
||||
- task: "Prioritize for next release cycle" # Title that will actually show in rituals table
|
||||
startedOn: "2023-08-09" # Needs to align with frequency e.g. if frequency is every thrid Thursday startedOn === any third thursday
|
||||
frequency: "Triweekly" # must be supported by https://github.com/fleetdm/fleet/blob/dbbb501358e226fa3fdf48865175efe3334c826c/website/scripts/build-static-content.js
|
||||
description: "Using your departmental kanban board, prioritize and finalize next sprint's goals for your team by draging the appropriate issues to the top of the 'Planned' column and archive everything in the 'Done' column."
|
||||
description: "Using your departmental kanban board, prioritize and finalize next release cycle's goals for your team by draging the appropriate issues to the top of the 'Planned' column and archive everything in the 'Done' column."
|
||||
moreInfoUrl: "https://fleetdm.com/handbook/company/why-this-way#why-make-work-visible" #URL used to highlight "description:" test in table
|
||||
dri: "allenhouchins" # DRI for ritual (assignee if autoIssue) (TODO display GitHub proflie pic instead of name or title)
|
||||
autoIssue:
|
||||
|
||||
@@ -335,11 +335,11 @@ After every GitOps workshop, Fleet issues a certificate to all participants who
|
||||
-->
|
||||
|
||||
|
||||
### Publish sprint demo video
|
||||
### Publish release demo video
|
||||
|
||||
After each sprint demo, the marketing team is responsible for doing a quick post-production pass on the recording and publishing it.
|
||||
After each release demo, the marketing team is responsible for doing a quick post-production pass on the recording and publishing it.
|
||||
|
||||
1. **Download the sprint demo recording**
|
||||
1. **Download the release demo recording**
|
||||
|
||||
This video is recorded and found in Gong. If the video is not uploaded, reach out to the CTO and Head of Product Design in the #help-marketing channel.
|
||||
|
||||
@@ -370,7 +370,7 @@ After each sprint demo, the marketing team is responsible for doing a quick post
|
||||
6. **Upload the video to Youtube**
|
||||
Follow the steps to [upload the video to YouTube](#upload-to-youtube).
|
||||
|
||||
Make sure the YouTube title follows the pattern `Sprint-demo - <version #.##.#>` (eg. "Sprint demo - 4.82.0").
|
||||
Make sure the YouTube title follows the pattern `Release-demo - <version #.##.#>` (eg. "Release demo - 4.82.0").
|
||||
|
||||
Add a brief description highlighting the new features.
|
||||
|
||||
@@ -379,7 +379,7 @@ After each sprint demo, the marketing team is responsible for doing a quick post
|
||||
|
||||
### Upload to YouTube
|
||||
|
||||
Fleet regularly uploads a variety of content to YouTube such as podcast episodes, sprint demos, educational updates, design reviews, and more.
|
||||
Fleet regularly uploads a variety of content to YouTube such as podcast episodes, release demos, educational updates, design reviews, and more.
|
||||
|
||||
- Login to the Fleet YouTube channel, click the create button and then upload the video.
|
||||
- Fill out relevant information such as:
|
||||
@@ -423,6 +423,9 @@ Although details on how to format and meta tag a blog are in [the writing handbo
|
||||
#### Stubs
|
||||
The following stubs are included only to make links backward compatible
|
||||
|
||||
##### Publish sprint demo video
|
||||
Please see [handbook/marketing#publish-release-demo-video](https://fleetdm.com/handbook/marketing#publish-release-demo-video)
|
||||
|
||||
##### Programs
|
||||
Please see [handbook/company/communications#product-marketing-programs](https://fleetdm.com/handbook/company/communications#product-marketing-programs)
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
-
|
||||
task: "Prioritize for next sprint" # Title that will actually show in rituals table
|
||||
task: "Prioritize for next release cycle" # Title that will actually show in rituals table
|
||||
startedOn: "2023-09-04" # Needs to align with frequency e.g. if frequency is every thrid Thursday startedOn === any third thursday
|
||||
frequency: "Triweekly"
|
||||
description: "Using your departmental kanban board, prioritize and finalize next sprint's goals for your team by draging the appropriate issues to the top of the 'Not yet' column." # example of a longer thing: description: "[Prioritizing next sprint](https://fleetdm.com/handbook/company/communication)"
|
||||
description: "Using your departmental kanban board, prioritize and finalize next release cycle's goals for your team by draging the appropriate issues to the top of the 'Not yet' column." # example of a longer thing: description: "[Prioritizing next release cycle](https://fleetdm.com/handbook/company/communication)"
|
||||
moreInfoUrl: "https://fleetdm.com/handbook/company/why-this-way#why-make-work-visible" #URL used to highlight "description:" test in table
|
||||
dri: "mikermcneil" # DRI for ritual (assignee if autoIssue) (TODO display GitHub proflie pic instead of name or title)
|
||||
-
|
||||
@@ -40,14 +40,14 @@
|
||||
task: "Process pending swag requests" # Title that will actually show in rituals table
|
||||
startedOn: "2025-04-02" # Needs to align with frequency e.g. if frequency is every thrid Thursday startedOn === any third thursday
|
||||
frequency: "Daily" # must be supported by
|
||||
description: "Complete draft orders." # example of a longer thing: description: "[Prioritizing next sprint](https://fleetdm.com/handbook/company/communication)"
|
||||
description: "Complete draft orders." # example of a longer thing: description: "[Prioritizing next release cycle](https://fleetdm.com/handbook/company/communication)"
|
||||
moreInfoUrl: "https://fleetdm.com/handbook/marketing#process-pending-swag-requests-from-the-website" #URL used to highlight "description:" test in table
|
||||
dri: "irenareedy" # DRI for ritual (assignee if autoIssue) (TODO display GitHub proflie pic instead of name or title)
|
||||
-
|
||||
task: "Publish ☁️🌈 Sprint demos"
|
||||
task: "Publish ☁️🌈 Release demos"
|
||||
startedOn: "2023-11-03"
|
||||
frequency: "Triweekly"
|
||||
description: "Every release cycle, upload the ☁️🌈 Sprint demos video to YouTube"
|
||||
description: "Every release cycle, upload the ☁️🌈 Release demos video to YouTube"
|
||||
moreInfoUrl: "https://fleetdm.com/handbook/marketing#upload-to-youtube"
|
||||
dri: "irenareedy"
|
||||
autoIssue:
|
||||
|
||||
@@ -34,9 +34,9 @@ Fleet's roadmap flows in this order (from highest to lowest fidelity):
|
||||
|
||||
### Triage new requests
|
||||
|
||||
The Head of Product Design is responsible for going through the inbox on the [drafting board](https://github.com/orgs/fleetdm/projects/67) and adding the correct [working group](https://fleetdm.com/handbook/company/product-groups#working-groups) label.
|
||||
The Head of Product Design is responsible for going through the inbox on the [drafting board](https://github.com/orgs/fleetdm/projects/67) and adding the correct [product group](https://fleetdm.com/handbook/company/product-groups#continuous-flow) label.
|
||||
|
||||
Once labeled, each working group's Product Designer (PD) is responsible for reviewing the inbox and deciding whether each new request contributes to Fleet's [product maturity](https://fleetdm.com/handbook/company/product-maturity-assessment) goals for the current calendar year. If yes, the PD adds the `~product-maturity` and `:product` labels so the request is reviewed at the next [unpacking the why](#unpacking-the-why) call. If a request doesn't meet these criteria but meets a different [criteria for prioritization](https://fleetdm.com/handbook/company/product-groups#criteria-for-prioritization), the PD removes the "Unpacked" checkbox in the feature request issue and either prioritizes a [user story or quick win](https://fleetdm.com/handbook/company/product-groups#scrum-items) to bring through [fast draft or full draft](https://fleetdm.com/handbook/company/product-groups#drafting-tracks-full-draft-vs-fast-draft), or sets it aside and adds it to the [feature fest](https://fleetdm.com/handbook/company/product-groups#feature-fest) board.
|
||||
Once labeled, each product group's Product Designer (PD) is responsible for reviewing the inbox and deciding whether each new request contributes to Fleet's [product maturity](https://fleetdm.com/handbook/company/product-maturity-assessment) goals for the current calendar year. If yes, the PD adds the `~product-maturity` and `:product` labels so the request is reviewed at the next [unpacking the why](#unpacking-the-why) call. If a request doesn't meet these criteria but meets a different [criteria for prioritization](https://fleetdm.com/handbook/company/product-groups#criteria-for-prioritization), the PD removes the "Unpacked" checkbox in the feature request issue and either prioritizes a [user story or quick win](https://fleetdm.com/handbook/company/product-groups#work-items) to bring through [fast draft or full draft](https://fleetdm.com/handbook/company/product-groups#drafting-tracks-full-draft-vs-fast-draft), or sets it aside and adds it to the [feature fest](https://fleetdm.com/handbook/company/product-groups#feature-fest) board.
|
||||
|
||||
|
||||
### Unpacking the why
|
||||
@@ -85,8 +85,8 @@ Additionally:
|
||||
- If the original request is a customer promise, specify what the due date is and who it's for.
|
||||
|
||||
- Sometimes a Product Designer in one product group drafts a user story or bug that will be specified, estimated, or implemented by another product group. This happens when the original group is constrained by design or engineering capacity. You'll know this is happening when they're a `assisting-g-*` label on the story or bug.
|
||||
- For example, if a #g-apple-at-work Product Designer drafts a story that #g-security-compliance will implement, the #g-apple-at-work Product Designer invites the #g-security-compliance Tech Lead to #g-apple-at-work design reviews. Once the story is approved, it’s brought to #g-security-compliance user story review.
|
||||
- At that point, the #g-security-compliance Product Designer becomes the [DRI](https://fleetdm.com/handbook/company/communications#directly-responsible-individuals-dris). They bring the story to their group’s estimation and handle questions from their team, coordinating with others as needed.
|
||||
- For example, if a #g-apple-at-work Product Designer drafts a story that #g-supply-chain will implement, the #g-apple-at-work Product Designer invites the #g-supply-chain Tech Lead to #g-apple-at-work design reviews. Once the story is approved, it’s brought to #g-supply-chain user story review.
|
||||
- At that point, the #g-supply-chain Product Designer becomes the [DRI](https://fleetdm.com/handbook/company/communications#directly-responsible-individuals-dris). They bring the story to their group’s estimation and handle questions from their team, coordinating with others as needed.
|
||||
|
||||
>**Questions and missing information:** Take a screenshot of the area in Figma and add a comment in the story's GitHub issue. Figma does have a commenting system, but we use GitHub issues so that all questions/conversation live in one place.
|
||||
>
|
||||
@@ -120,16 +120,16 @@ changing specifications while ensuring that Fleet meets our brand and quality gu
|
||||
You'll know it's time for expedited drafting when:
|
||||
- The team discovers that a drafted user story is missing crucial information that prevents contributors from continuing the development task.
|
||||
- A user story is taking more effort than was originally estimated, and Product Designer (PD) wants to find ways to cut aspects of planned functionality in order to still ship the improvement in the currently scheduled release.
|
||||
- A user story on the drafting board wasn't estimated by the last estimation session in the current sprint and cannot wait until the next sprint. This can also happen when we decide to bring a user story in mid-sprint.
|
||||
- A user story on the drafting board wasn't estimated by the last estimation session in the current release cycle and cannot wait until the next release. This can also happen when we decide to bring a user story in mid-release cycle.
|
||||
|
||||
|
||||
What happens during expedited drafting?
|
||||
|
||||
1. If we cut planned functionality, the PD notifies the [customer support DRI](https://fleetdm.com/handbook/company/communications#directly-responsible-individuals-dris). Up to the PD to let the customer support DRI know if we're still planning on building the functionality in a later release and if so, when. The customer support DRI should confirm that the updated scope and/or timeline still meets the requester's needs.
|
||||
2. The PD notifies the [DRI for what goes in a release](https://fleetdm.com/handbook/company/communications#directly-responsible-individuals-dris) (release DRI), Head of Product Design, and the relevant product group's Engineering Manager (EM) in the `#help-leadership` Slack channel.
|
||||
- If the user story wasn't "Ready for spec" by the last estimation session, decision to allow the user story to make it into the next engineering sprint is up to the release DRI.
|
||||
- If the user story is in the current engineering sprint and there are significant changes to the requirements, then the user story might be pushed to the next sprint. Decision is up to the release DRI.
|
||||
3. Drafts are updated, changes [are approved](https://fleetdm.com/handbook/company/development-groups#drafting-process), and the user story is estimated or brought back into the current sprint.
|
||||
- If the user story wasn't "Ready for spec" by the last estimation session, decision to allow the user story to make it into the next engineering release cycle is up to the release DRI.
|
||||
- If the user story is in the current engineering release cycle and there are significant changes to the requirements, then the user story might be pushed to the next release. Decision is up to the release DRI.
|
||||
3. Drafts are updated, changes [are approved](https://fleetdm.com/handbook/company/development-groups#drafting-process), and the user story is estimated or brought back into the current release cycle.
|
||||
|
||||
|
||||
### Consider a feature eligible to be flagged
|
||||
@@ -180,14 +180,14 @@ The Head of Product Design (HPD), Product Designers (PD), and the relevant Custo
|
||||
|
||||
If the original request is a customer request, it's up to the relevant CSA to decide if the request is fulfilled. If it is, we assign the relevant Customer Success Manager (CSM) and add the `:help-customers` label to add the customer request to the [🌦️ :help-customers board](https://github.com/orgs/fleetdm/projects/79).
|
||||
|
||||
### Notify stakeholders when a user story is pushed to the next sprint
|
||||
### Notify stakeholders when a user story is pushed to the next release
|
||||
|
||||
[User stories](https://fleetdm.com/handbook/company/product-groups#scrum-items) are intended to be [drafted](#drafting) and estimated in a single sprint. When the Product Designers (PD) knows a user story will be pushed, it is the PD's responsibility to notify stakeholders:
|
||||
[User stories](https://fleetdm.com/handbook/company/product-groups#work-items) are intended to be [drafted](#drafting) and estimated in a single release cycle. When the Product Designers (PD) knows a user story will be pushed, it is the PD's responsibility to notify stakeholders:
|
||||
|
||||
1. Comment on the GitHub issue and at-mention the Head of Product Design and [release DRI](https://fleetdm.com/handbook/company/communications#directly-responsible-individuals-dris).
|
||||
2. If `customer-` labels are applied to the user story, at-mention the [VP of Customer Success](https://fleetdm.com/handbook/customer-success#team) in the #g-apple-at-work, #g-auto-patching, #g-orchestration, or #g-security-compliance Slack channel.
|
||||
2. If `customer-` labels are applied to the user story, at-mention the [VP of Customer Success](https://fleetdm.com/handbook/customer-success#team) in the relevant [product group's](https://fleetdm.com/handbook/company/product-groups#current-product-groups) Slack channel.
|
||||
|
||||
> Instead of waiting until the end of the sprint, notify stakeholders as soon as you know the story is being pushed.
|
||||
> Instead of waiting until the end of the release cycle, notify stakeholders as soon as you know the story is being pushed.
|
||||
|
||||
|
||||
### Update a company brand front
|
||||
@@ -212,6 +212,8 @@ When a new major macOS version is announced, it's the Head of Product Design's r
|
||||
#### Stubs
|
||||
The following stubs are included only to make links backward compatible.
|
||||
|
||||
##### Notify stakeholders when a user story is pushed to the next sprint
|
||||
Please see [handbook/product-design#notify-stakeholders-when-a-user-story-is-pushed-to-the-next-release](https://fleetdm.com/handbook/product-design#notify-stakeholders-when-a-user-story-is-pushed-to-the-next-release).
|
||||
|
||||
|
||||
<meta name="maintainedBy" value="noahtalerman">
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
-
|
||||
task: "🦢📊 Product design sprint review" # 2024-03-06 TODO: Link to responsibility or corresponding "how to" info e.g. https://fleetdm.com/handbook/company/product-groups#making-changes
|
||||
startedOn: "2024-03-07"
|
||||
frequency: "Triweekly"
|
||||
description: "1. For all stories, targeted for the next sprint, that are not estimated, update their milestone. 2. For stories that we're no longer working on, remove them from the drafting board, remove them from the release planning board, and notify stakeholders. 3. Prepare the '🎁 Feature fest' board."
|
||||
task: "🦢📊 Product design review" # 2024-03-06 TODO: Link to responsibility or corresponding "how to" info e.g. https://fleetdm.com/handbook/company/product-groups#making-changes
|
||||
startedOn: "2024-03-07"
|
||||
frequency: "Triweekly"
|
||||
description: "1. For all stories, targeted for the next release cycle, that are not estimated, update their milestone. 2. For stories that we're no longer working on, remove them from the drafting board, remove them from the release planning board, and notify stakeholders. 3. Prepare the '🎁 Feature fest' board."
|
||||
moreInfoUrl:
|
||||
dri: "noahtalerman"
|
||||
-
|
||||
@@ -13,7 +13,7 @@
|
||||
moreInfoUrl: "https://fleetdm.com/handbook/company/product-groups#feature-fest"
|
||||
dri: "noahtalerman"
|
||||
-
|
||||
task: "Product design sprint kickoff" # 2024-03-06 TODO: Link to responsibility or corresponding "how to" info e.g. https://fleetdm.com/handbook/company/product-groups#making-changes
|
||||
task: "Product design kickoff" # 2024-03-06 TODO: Link to responsibility or corresponding "how to" info e.g. https://fleetdm.com/handbook/company/product-groups#making-changes
|
||||
startedOn: "2024-03-07"
|
||||
frequency: "Triweekly"
|
||||
description: "1. Pull up all contributors' calendars to review time off and, if needed, update design review calendar events. 2. Create reference docs release branches for any milestones newly added to the drafting board 3. For feature requests prioritized during feature fest, add user stories to the drafing and release planning boards, add milestones to the stories, confirm available capacity in targeted release, and align on priorities."
|
||||
@@ -105,14 +105,14 @@
|
||||
task: "📝 Understanding our competitor(s)"
|
||||
startedOn: "2026-01-26"
|
||||
frequency: "Weekly"
|
||||
description: "For each user story in the current design sprint, find a solution using our competitor(s) tools. Discuss how this solution affects how we're thinking about the Fleet solution. For each story, do we just want to be as good as our competitor(s)? Better?"
|
||||
description: "For each user story in the current release cycle, find a solution using our competitor(s) tools. Discuss how this solution affects how we're thinking about the Fleet solution. For each story, do we just want to be as good as our competitor(s)? Better?"
|
||||
moreInfoUrl:
|
||||
dri: "noahtalerman"
|
||||
-
|
||||
task: "Review reference docs for upcoming release"
|
||||
startedOn: "2025-10-20"
|
||||
frequency: "Triweekly"
|
||||
description: "After sprint kickoff: 1. Check for API design PRs on estimated stories that were not brought into the sprint, then @-mention the product designer to request documentation changes be reverted. 2. Check for unmerged API design PRs on the release docs branch (filter: is:pr is:open base:docs-vX.X.X). For stories that made it into the sprint, merge the PR. For stories that did not make it in, close the PR and @-mention the author."
|
||||
description: "After kickoff: 1. Check for API design PRs on estimated stories that were not brought into the release cycle, then @-mention the product designer to request documentation changes be reverted. 2. Check for unmerged API design PRs on the release docs branch (filter: is:pr is:open base:docs-vX.X.X). For stories that made it into the release cycle, merge the PR. For stories that did not make it in, close the PR and @-mention the author."
|
||||
moreInfoUrl: ""
|
||||
dri: "rachaelshaw"
|
||||
autoIssue:
|
||||
|
||||
+1
-1
@@ -530,7 +530,7 @@
|
||||
</dict>
|
||||
<dict>
|
||||
<key>name</key>
|
||||
<string>🛡️ Current sprint (#g-security-compliance)</string>
|
||||
<string>🛡️ Current sprint (#g-supply-chain)</string>
|
||||
<key>url</key>
|
||||
<string>https://github.com/orgs/fleetdm/projects/97</string>
|
||||
</dict>
|
||||
|
||||
@@ -31,7 +31,7 @@ type BugIssue struct {
|
||||
} `json:"labels"`
|
||||
}
|
||||
|
||||
var productGroupLabels = []string{"#g-software", "#g-orchestration", "#g-mdm", "#g-security-compliance"}
|
||||
var productGroupLabels = []string{"#g-software", "#g-orchestration", "#g-mdm", "#g-supply-chain"}
|
||||
|
||||
func (i BugIssue) ProductGroup() string {
|
||||
for _, label := range i.Labels {
|
||||
|
||||
@@ -12,7 +12,7 @@ import (
|
||||
// when syncing to Releases: drafting and product group projects.
|
||||
func DefaultEstimateSourceProjects() []int {
|
||||
// unique list; ignore releases itself (87) as a source
|
||||
return []int{Aliases["draft"], Aliases["mdm"], Aliases["g-software"], Aliases["g-orchestration"], Aliases["g-security-compliance"]}
|
||||
return []int{Aliases["draft"], Aliases["mdm"], Aliases["g-software"], Aliases["g-orchestration"], Aliases["g-supply-chain"]}
|
||||
}
|
||||
|
||||
// GetEstimateFromProject returns the numeric estimate for an issue from a specific project.
|
||||
|
||||
@@ -13,25 +13,28 @@ import (
|
||||
)
|
||||
|
||||
var Aliases = map[string]int{
|
||||
"mdm": 58,
|
||||
"g-mdm": 58,
|
||||
"draft": 67,
|
||||
"drafting": 67,
|
||||
"g-software": 70,
|
||||
"soft": 70,
|
||||
"g-orchestration": 71,
|
||||
"orch": 71,
|
||||
"sec": 97,
|
||||
"g-security-compliance": 97,
|
||||
"releases": 87,
|
||||
"mdm": 58,
|
||||
"g-mdm": 58,
|
||||
"draft": 67,
|
||||
"drafting": 67,
|
||||
"g-software": 70,
|
||||
"soft": 70,
|
||||
"g-orchestration": 71,
|
||||
"orch": 71,
|
||||
"sec": 97,
|
||||
"g-supply-chain": 97,
|
||||
"byod": 112,
|
||||
"g-byod": 112,
|
||||
"releases": 87,
|
||||
}
|
||||
|
||||
// ProjectLabels maps project IDs to their corresponding label filters for the drafting project
|
||||
var ProjectLabels = map[int]string{
|
||||
58: "#g-mdm", // mdm project
|
||||
70: "#g-software", // g-software project
|
||||
71: "#g-orchestration", // g-orchestration project
|
||||
97: "#g-security-compliance", // g-security-compliance project
|
||||
58: "#g-mdm", // mdm project
|
||||
70: "#g-software", // g-software project
|
||||
71: "#g-orchestration", // g-orchestration project
|
||||
97: "#g-supply-chain", // g-supply-chain project
|
||||
112: "#g-byod", // g-byod project
|
||||
}
|
||||
|
||||
// ResolveProjectID resolves a project identifier (alias or numeric string) to a project ID.
|
||||
|
||||
@@ -124,16 +124,19 @@ func TestParseJSONtoProjectItems(t *testing.T) {
|
||||
|
||||
func TestAliases(t *testing.T) {
|
||||
expectedAliases := map[string]int{
|
||||
"mdm": 58,
|
||||
"g-mdm": 58,
|
||||
"draft": 67,
|
||||
"drafting": 67,
|
||||
"g-software": 70,
|
||||
"soft": 70,
|
||||
"g-orchestration": 71,
|
||||
"orch": 71,
|
||||
"sec": 97,
|
||||
"g-security-compliance": 97,
|
||||
"mdm": 58,
|
||||
"g-mdm": 58,
|
||||
"draft": 67,
|
||||
"drafting": 67,
|
||||
"g-software": 70,
|
||||
"soft": 70,
|
||||
"g-orchestration": 71,
|
||||
"orch": 71,
|
||||
"sec": 97,
|
||||
"g-supply-chain": 97,
|
||||
"byod": 112,
|
||||
"g-byod": 112,
|
||||
"releases": 87,
|
||||
}
|
||||
|
||||
if !reflect.DeepEqual(Aliases, expectedAliases) {
|
||||
|
||||
@@ -390,7 +390,8 @@ create_qa_issue() {
|
||||
--assignee "AndreyKizimenko" --label "#g-apple-at-work" --label ":release" \
|
||||
--label "#g-auto-patching" \
|
||||
--assignee "xpkoala" --label "#g-orchestration" \
|
||||
--label "#g-security-compliance"
|
||||
--label "#g-supply-chain" \
|
||||
--label "#g-byod"
|
||||
rm -f temp_qa_issue_file
|
||||
fi
|
||||
else
|
||||
|
||||
Reference in New Issue
Block a user