mirror of
https://github.com/fleetdm/fleet
synced 2026-05-23 17:08:53 +00:00
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:
parent
102d80e463
commit
1becf7ebe6
1 changed files with 2 additions and 3 deletions
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Reference in a new issue