Add scrum documentation to handbook (#9333)

Co-authored-by: Zach Wasserman <zach@fleetdm.com>
This commit is contained in:
Sharon Katz 2023-01-13 20:38:52 -05:00 committed by GitHub
parent 57b8ff2414
commit 190ff2cb82
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -5,7 +5,8 @@
### In this section
- [Goals](#goals)
- [Principles](#principles])
- [Principles](#principles)
- [Scrum](#scrum)
- [Eng Together](#eng-together)
- [Release Retro](#release-retro)
- [Group Weeklies](#group-weeklies)
@ -28,6 +29,25 @@
The following is the subset of proposed engineering meetings. Each group is free to treat these as a subset of the expected meetings and add any other meetings as they see fit.
### Scrum
- Fleet engineering teams practice scrum as an agile methodology.
- Sprints are 3 weeks long to match our release cadence.
- There are 5 “Scrum Ceremonies” performed during each sprint:
- Sprint planning - At the first Monday of the sprint the team and stakeholders meet and pick items from the backlog. The team commit to finish those items.
- Daily sync standup - The team meet daily for updates. Each team member present what they did since the last sync and what they intend to do until next sync. Any impediments are raised.
- Weekly estimation sessions - once a week (3 times a sprint) the team will estimate items in the backlog. Goals:
- Have Stakeholders know in advance the time it will take to achieve those items.
- Make it easier in the next planning meeting to know what the team can take for the next sprint.
- Sprint Demo - At the last Friday of the sprint all engineering teams and stakeholders meet to present their work. Engineers will get 3-10 minutes to present what was done / not done.
- Sprint Retrospective - At the last Friday of the sprint each team will meet with stakeholders and hold a discussion answering the 3 questions:
- What went well?
- What could we have done better?
- What did we learn?
- Scrum items:
- Objectives / Epics: TBD - Will probably not be used (further discussion needed)
- User Story - A description of missing functionality typically visible by our customers. The description answers three questions: Who is the user that wants it? What is the task? What is the purpose of it (what problem it solves or what value it adds)? Typically written in this format: As the &lt;user&gt; I would like to &lt;have something done or changed&gt; so that I can &lt;benefit from it in this specific way&gt;. A Story will include all the tasks required in order to achieve it or will have technical-sub-task(s) bound to it.
- Technical Sub Task - Typically a task that is part of a bigger Story. e.g. design, code, create a test/document. Will typically be blocking the Story they are part of.
### Eng Together
This is to promote cohesion across groups within the engineering team. Disseminate engineering-wide announcements. Held weekly for one hour.