From 1becf7ebe6af388fa5c2a8557f2f2ff671437cfa Mon Sep 17 00:00:00 2001
From: Luke Heath <luke@fleetdm.com>
Date: Thu, 8 Feb 2024 15:41:06 -0600
Subject: [PATCH] Add engineering-initiated stories back to handbook (#16656)

In favor of being succinct, I omitted the specifics. Let me know if you
think I should add them or if this PR is reference enough:

1. Not more than 10% of the sprint.
2. Not every sprint; only when there is clear business value.
3. Is used for boring solutions only (not chasing new and shiny tech).
4. I will be DRI for determining when and what to prioritize. I will tag
@noahtalerman any time this happens.
5. @noahtalerman's decision if it changes an interface (UI/API/CLI) or
config surface or changes that require extra work from users (uptime or
manual migration).
---
 handbook/company/product-groups.md | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/handbook/company/product-groups.md b/handbook/company/product-groups.md
index caaf19b3e4..de84c82e37 100644
--- a/handbook/company/product-groups.md
+++ b/handbook/company/product-groups.md
@@ -141,16 +141,15 @@ 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 valuable enough? Will this task drive business value when released, independent of other tasks?
 
-<!--
+
 #### Engineering-initiated stories
 Engineering-initiated stories are types of user stories created by engineers to make technical changes to Fleet. Technical changes should improve the user experience or contributor experience. For example, optimizing SQL that improves the response time of an API endpoint improves user experience by reducing latency. A script that generates common boilerplate, or automated tests to cover important business logic, improves the quality of life for contributors, making them happier and more productive, resulting in faster delivery of features to our customers.
 
 It is important to frame engineering-initiated user stories the same way we frame all user stories. Stay focused on how this technical change will drive value for our users.
 
-To [create an engineering-initiated user story](https://fleetdm.com/handbook/engineering#creating-an-engineering-initiated-story), follow the [user story drafting process](https://fleetdm.com/handbook/company/development-groups#drafting). Once your user story is created using the [new story template](https://github.com/fleetdm/fleet/issues/new?assignees=&labels=story%2C%3Aproduct&projects=&template=story.md&title=), add the `~engineering-initiated` label, assign it to yourself, and work with an EM or PM to progress the story through the drafting process.
+To [create an engineering-initiated user story](https://fleetdm.com/handbook/engineering#creating-an-engineering-initiated-story), follow the [user story drafting process](https://fleetdm.com/handbook/company/development-groups#drafting). Once your user story is created using the [new story template](https://github.com/fleetdm/fleet/issues/new?assignees=&labels=story,~engineering-initiated&projects=&template=story.md&title=), add the `~engineering-initiated` label, assign it to yourself, and bring to your EM to be considered for future prioritization into a sprint. The engineering output and architecture DRI is responsible for prioritizing engineering-initiated stories.
 
 > We prefer the term engineering-initiated stories over technical debt because the user story format helps keep us focused on our users.
--->
 
 #### Defining "done"
 To successfully deliver a user story, the people working on it need to know what "done" means.