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).
This commit is contained in:
Luke Heath 2024-02-08 15:41:06 -06:00 committed by GitHub
parent 102d80e463
commit 1becf7ebe6
No known key found for this signature in database
GPG key ID: B5690EEEBB952194

View file

@ -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.