Add new timebox scrum item and related documentation (#12929)

There have been several tickets created for investigation or research
purposes like [this one ](https://github.com/fleetdm/fleet/issues/12904)
that we don't have a ticket type for within our current three types
(`story`, `~sub-task`, and `bug`). This results in the existing scrum
item types needing to be misused. I'm adding a fourth type called
`timebox` at Mike's request. I'm also including documentation on the
usage of this new type.

Lastly, I'm proposing we stop calling sub-tasks "unestimated sub-tasks"
in the GitHub template because it is confusing and inaccurate. Our
documentation states: "Sub-tasks are labeled as `~sub-task` and enable
us to break down complex tasks into more detailed and easier-to-estimate
work units.". In our estimation sessions, we put point estimates on
sub-tasks.

The spirit of this statement is that all sub-task points bubble up to
their parent story, and the parent story is what matters to the rest of
the business. That is clearly defined in our documentation and processes
and will not confuse our usage of stories.

---------

Co-authored-by: Mike McNeil <mikermcneil@users.noreply.github.com>

.github/ISSUE_TEMPLATE/sub-task.md

@@ -1,6 +1,6 @@
 ---
-name: 🧩  Unestimated sub-task
-about: "Specify an unestimated sub-task. (Avoid comments.  Use only as prescribed.)"
+name: 🧩 Sub-task
+about: "Specify a sub-task. (Avoid comments.  Use only as prescribed.)"
 title: ''
 labels: '~sub-task'
 assignees: ''
@@ -10,7 +10,7 @@ assignees: ''
 ## Related user story
 
 TODO
-<!-- An unestimated sub-task always belongs to exactly one story.  The parent user story for this technical sub-task is linked here.   Comment on the parent story, not on this sub-task. -->
+<!-- A sub-task always belongs to exactly one story.  The parent user story for this technical sub-task is linked here.  Comment on the parent story, not on this sub-task. -->
 
 ## Task
 
@@ -20,5 +20,4 @@ TODO
 ## Condition of satisfaction
 
 TODO
-
-<!-- Describe the conditions of satisfaction that will resolve this issue.  The "definition of done". It is always up to contributors to check their own work.  But especially keep in mind there is no external quality assurance check for sub-tasks.  (Only user stories get automatic external QA.  With unestimated sub-tasks, it's up to you.)  -->
+<!-- Describe the conditions of satisfaction that will resolve this issue.  The "definition of done". It is always up to contributors to check their own work.  But especially keep in mind there is no external quality assurance check for sub-tasks.  (Only user stories get automatic external QA.  With sub-tasks, it's up to you.)  -->

.github/ISSUE_TEMPLATE/timebox.md

@@ -0,0 +1,22 @@
+---
+name: ⏳ Timebox
+about: Specify an effort that will be completed within a pre-defined amount of time.
+title: ''
+labels: 'timebox'
+assignees: ''
+
+---
+
+## Related user story
+
+TODO
+
+## Task
+
+TODO
+<!-- What needs to be learned. -->
+
+## Condition of satisfaction
+
+TODO
+<!-- Describe the conditions of satisfaction that will resolve this issue.  The "definition of done". It is always up to contributors to check their own work. -->

handbook/engineering/README.md

@@ -31,15 +31,17 @@ New tickets are estimated, specified, and prioritized on the roadmap:
 
 ### Scrum items
 
-Our scrum boards are exclusively composed of three types of scrum items:
+Our scrum boards are exclusively composed of four types of scrum 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. Occasionally, due to ZenHub's ticket sub-task structure, the term 'epic' may be seen. However, we treat these as regular user stories.
 
-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.
+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. **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. Bugs [may be estimated or left unestimated](https://fleetdm.com/handbook/engineering#do-we-estimate-released-bugs-and-outages), as determined by the product group's engineering manager.
+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.
 
-> Our sprint boards do not accommodate any other type of ticket. By strictly adhering to these three types of scrum items, we maintain an organized and focused workflow that consistently adds value for our users.
+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. Bugs [may be estimated or left unestimated](https://fleetdm.com/handbook/engineering#do-we-estimate-released-bugs-and-outages), as determined by the product group's engineering manager.
+
+> Our sprint boards do not accommodate any other type of ticket. By strictly adhering to these four types of scrum items, we maintain an organized and focused workflow that consistently adds value for our users.
 
 ## Meetings