Skip to end of metadata
Go to start of metadata

Child pages:

GDP Wiki Page Templates

The core GDP development team follows a lightweight process most similar to Scrum.  (Youtube: SCRUM in 2 minutes. In 7 minutes, and others)

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)

Sprint names

2021 - means a sprint spanning calendar week 20 and  21.
2223 - the name of the next sprint.

Week numbers are according to ISO-8601 standard.  Here is an online calendar - week numbers in the rightmost column.

Names are selected from this list:

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

Meeting schedule

The Core team works in the CET time zone.
The tiles link to detailed process description.

(warning) 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
    • (warning) 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.

JIRA status

  • 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:

Grouping tickets

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 AnderssonMirza 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

  • No labels