Agile Process

The agile process @FCHH will be introduced on this page.

If you are not familiar with Agile (aka Scrum) you might check some of the additional resources at the bottom.

However a very minimalistic approach is introduced to give enough freedom to everybody while still ensuring the necessary common workflow needed to start working agile.

*Image: The standard "Textbook-like" Process of Scrum*

Agile Process @ FCHH

To get started, we focus on 3 main pillars of agile process management. This is a „light“ version of the agile concept. As we get more experienced we might discover more useful elements.


  • We work with GitLab Milestones (aka sprints). A milestone usually takes 2 Weeks and ends with a Demo Day.
  • When a Sprint starts, it is the task of the team to achieve the defined goals together. Team performance is easier to improve than individual performance.

Demo Days

  • You will plan your tasks with the goal to have valuable outcomes that can be shipped and presented at a Demo Day. Basically everybody is invited. It's a great way to stay inspired and see what everybody is doing.


  • The GitLab issues functionality offers you all the management features you need for execution. From defining task to resource planing, co-working, and many more. We encourage you to learn and master this tool.

  • The issue template helps you with a good structure.
    Value Proposition: Make the purpose, value or benefit of the that issue clear!
    Resources/Notes: Ask yourself what others may need to complete that issue and reduce back and forth issue pushing!
    Acceptance Criteria: Very important! Make your expectation of the result as clear as possible! Think of important pitfalls (e.g. " - [ ] Don't forget to test that feature with my grandma's PC"

Adding an Issue template to a GitLab project

If your GitLab project should have a template to chose from, please follow this GitLab Guide. Groups cannot have issue templates.
Example is found here:


Sprint Planing

Sprints are for Fab City OS (global for all teams)

  • We plan our tasks (issues) for Fab City OS inside of regular sprints in a Sprint-planning event at the beginning of the sprint to avoid chaos and unclear focus.
  • We ensure that tasks have a clear purpose, always serve the product vision of Fab City OS and have all the relevant information needed to be accomplished without misunderstanding.
  • We plan, execute and present sprints as our core rhythm for a productive and fun team process.
  • In a joint meeting it is checked that all tasks meet the requirements, open questions are clarified and that the number of issues corresponds to the team capacity (cf. Velocity, story-points).
  • The goal of the SP is to prioritize the issues for the next milestone.
  • Issues must therefore be well thought out. An issue contains:
    • Clear task definition with clear added value for the product vision. What why for whom? It must be understandable for all.
    • Clear acceptance criteria when a task is done (definition of done). What is expected? A prototype, a link to the result, extensive tests?
    • An issue must be complete and contain all additional information so that team members can work on the task. Where is additional information, possible contact persons, results of previous issues to be considered, etc.?
    • Sprints always have a part (an increment) of the product vision (PV) as a goal. Ideally a prototype of a new feature (typical for developers). In areas like research or marketing it might be useful analysis, campaigns or texts. It is the task of the PO to always ask what added value the tasks will bring to the PV.

Note: with innovative products, things often have to be tried out because many things did not exist before. So issues can often contain MVPs. So a Sprint can use test version, cardboard models or design thinking methods to get valuable insights for the upcoming Sprints.


It's a short 15min meeting in the morning to check what everybody is up to.
The purpose of the Daily Scrum is to inspect and synchronize the team's progress towards the Sprint Goal, discuss if anything impedes the team and re-plan the team's work to achieve the Sprint Goal.

Demo Day (aka Sprint Review)

We call our Sprint Review "Demo Day" because its a nice easily recognizable name.

Conducted at the end of a sprint, the team:

  • technology demo
  • collaborates with stakeholders on topics such as:
    • inviting feedback about the completed product increment
    • discussing the impact of incomplete work (planned or otherwise)
    • receiving suggestions for upcoming work (guidance of what to work on next)

Product Owners should see this event as a valuable opportunity to review and refine the product backlog with stakeholders.

Guidelines for sprint reviews:

  • Incomplete work should not be demonstrated; although stakeholders should be presented with product increments they will be receiving, they can also request to see work in progress if necessary. However, the team should only be prepared to show what has been done.
  • The recommended duration is two hours for a two-week sprint (proportional for other sprint-durations).

Sprint Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

Meetings will be announced in close relation to demo days


Groups, Projects and Issues

  • You can only create an Issue inside of a project
  • A group can display and filter all issues of child-projects
  • Users of a Group also have access to a child-project
  • Group Labels and Milestones apply to child-projects
  • GitLab project = Repository (Repo)


  • The backlog (BL) (..) is to be maintained by the product owner (PO). He and the scrum master take the tasks of the BL and prepare the sprint planning.
  • Everyone can write issues into the backlog, and this is explicitly wanted, but only as a collection point for tasks.
  • The teams only work in milestones. This prevents uncoordinated work (issues) from being created and assigned.
  • It is the task of the Product Owner is to prepare the next Sprint Planning during the current Sprint. I.e. to read and prioritise tasks. When there is ambiguity, team members are contacted and issues are handled accordingly.


We are using Fab City names, hoping that many more will join so we don't run out.

  • 1st "Barcelona Sprint"
  • 2nd "Zagreb Sprint"
  • ....

Barcelona Zagreb Thimphu Shenzhen Georgia Curitiba Occitanie Region Puebla Mexico City Auvergne-Rhône-Alpes Amsterdam Cambridge Kerala Sacramento Plymouth Hamburg Yucatàn Region Valence Romans Agglo Bas-Saint-Laurent Belo-Horizonte Ekurhuleni Brest Boston Toulouse Paris Santiago Velsen Seoul Oakland Somerville Detroit Kamakura Sorocaba Rennes São Paolo Recife Linz Zadar

You can write an Issue by using the Template within a new Issue



For any agile related questions please contact Raphael

Last edit on 05.04.2022 at 10:12 h