- Backlog Refinement
- GDP generic Definition of Done (DoD)
- GDP Process: Sprint Close and Retrospective
- GDP Tools and Project Organization
Contributions from outside developers are accepted at any time, and we communicate with contributors all the time. Whenever a contribution needs non-trivial integration it must however be introduced into the team backlog. We therefore recommend contributors to create a JIRA ticket for all non-trivial contributions, in addition to their pull-request.
Product Vision Statement
To be written.
Consider the GDP-next presentation from the most recent All Member Meeting.
Sprints are usually 2 weeks long. (We have also tried 1 week sprints).
Sprints run from Monday afternoon to Friday (Monday morning used for finalization - Monday afternoon for retrospective & sprint plan)
2021 - means a sprint spanning calendar week 20 and 21.
2223 - the name of the next sprint.
Names are selected from this list: https://en.wikipedia.org/wiki/List_of_Star_Wars_creatures
To make names easy to distinguish a, a new letter is used for each sprint. In other words, the first name starting with A, followed by the first name in section "B", "C", and so on. When it wraps around, use the second name starting with "A", then the second starting with "B", and so on.
Combining calendar-week numbers and name, the sprint name looks like this: 2122_Air_Shrimp
Product and Sprint Backlog
The Core team works in the CET time zone.
The tiles link to detailed process description.
To be updated
- Stand-ups (a.k.a. "Daily Scrum") - once per day at 09:42. Typically using video conferencing tools. Currently using: [gunnartalk].
- Retrospective - replaces stand-up on Thursday.
- Sprint planning, Thursday following Retrospective.
- Backlog refinement/grooming, Monday 10.00
- Sprint review (preparation) - Wednesday 2 PM. Team only.
- Sprint review (report) - during GDP Community meeting,
- Sprint demo - when applicable, done on GDP Community meeting.
- GDP Community meeting: Wednesdays 4PM CET/CEST (TBC) (Zoom link TBD)
- Team Members
- To be updated
- Product Owner In practice today it is the combination of people making up the PMO team. Input is taken from community to the working team / Development Lead.
- Scrum Master - we have none but all team members are well experienced with SCRUM.
JIRA issue types for GDP maintenance project
There are four main issue types:
- Epic *: Major Feature or Work Package. Anything requiring multiple Tasks.
- Task: Default work package unit. If it's a new feature, prefer Feature.
- Sub-Task: Possible but generally avoided because they are not visibly scheduled in the Scrum setup.
- Feature: It is a Task that also creates new functionality. It has the same level as Task . Refer to Definition of Done for when to use Feature and what it requires.
- Bug: Problem.
Note that we no longer use Epics to group features for a particular release, or that belong logically together for reasons other than being steps to implement a single thing.
- Request / Analysis: any work that comes from a contributor or internally needs to be evaluated before assuming the commitment to execute it. This stage will be assigned to those work packages that are being evaluated.
- Todo / Backlog: when the work packages are approved, they get into the backlog of the team.
- In progress: work that is being done. A person started work on the topic. This can be a person in the main development team, or outside contributor.
- In Review: acceptance checks before considering a task done.
- Done / Closed: Work packaged has been finished or, for a variety of reasons, won't be done. Closed issues can be reopened.
Ticket done and acceptance criteria:
There are many ways to filter and group components to study them in different views. These are the preferred ways:
- Epic (For a larger but still single work package / feature. We do not use it for grouping things in time or other logical grouping)
- Assign tasks to a Release
- Assign tasks to a Component
- Use Labels only if none of the above covers the need.
- Feature content is defined by assigning Epics to JIRA Releases, e.g. GDP 13
Each ticket shall be assigned to a Component. There is only a small set of components and no fine-grained division:
- GDP Master component means "any part of the embedded system" (if not a Spin).
- CIAT deals with the continuous integration infrastructure
- Perhaps a slight misuse of Component concept -- the name Process is for questions relating to working process
- ...and a few others.
- Labels are mostly avoided, instead prefer Epic, Release and Component fields for grouping.
- Some labels from before are temporarily kept (<=GDP11 releases, etc.)
- For backlog quality improvements the labels "Refined" and "NeedRefinement" are used to create groups of tickets to look at (or not).
- If another temporary grouping is needed, the team might use other temporary labels.
Change history, etc.
Updating for 2018 by Gunnar Andersson, Mirza Krak, ...
Created, reviewed & modified with Gunnar Andersson, Oscar Andreasson & Viktor Sjölind 2017-05-18.
Added Product Vision Statement, Roles, ... Gunnar Andersson (old account, disabled) 2017-05-30
Move all ticket-related process rules from other pages, and update them Gunnar Andersson 2017-11-27