Skip to content

10 ‐ Sprint management, issues, validation and release processes

Jump to bottom
Pierre-Yves Lapersonne edited this page Dec 19, 2024 · 4 revisions

Working with sprints and board

Sprints

We work with sprints of 3 weeks, which means we plan to make a new release each 3 weeks, in a kind of Kanban mode. Each end of sprint implies internal meetings as sprint demo, sprint review / retro* and sprint grooming. Things shown at sprint demo should be done things or almost done, but it is possible to show some work in progress.

Releases

This is the duty of the development team to define the versions of the releases (using semantic versioning and to say wether or not something can be shipped or not. We try until now to ship new release each end of sprint (i.e. 3 weeks). When we have a good idea of what will be shipped, i.e. near the end of the sprint, the development team can make release candidate tags.

Issues and board

A GitHub project exists at the organization level with also a focus on the iOS project. In that board, you will find several columns:

  • No status for issues without statuses, we did not check them yet
  • Triage for issues to process in the future
  • Todo for issues to process in the current sprint
  • In Progress for issues the development team is working on
  • In Review for issues for which impllementations has been made, reviewed, can be merged but need validation of product owner, accessibility referent and design team
  • Done for any done and merge issues

Definition of ready

We can define the definition of ready for issues as the following set of conditions:

  • design for the demo app updated
  • components, semantic, raw tokens available
  • design of the component / module / feature ready

Definition of done

We can define the definition of done for issues as the following set of conditions:

  • demo app has been updated
  • tokens (components, semantics, raws) updated
  • component / feature / module implemented
  • unit tests implemented
  • UI tests implemented
  • documentation updated (both Swift doc and DocC catalog)
  • design team reviewed the evolution
  • a11y expert reviewed the evolution
  • PO reviewed the evolution
  • Q/A team tested the evolution

This definition of done then relies strongly on alpha builds, and is also recalled in our pull request template

Use of issues labels

Issues must appear somewhere in the board. Labels must be used to bring clarity, here are some you should use:

  • 💥 blocking if the issue cannot be processed for some blocking reason
  • ⚠ on hold if the issue should not be processed yet because for example of a dependency
  • 📱 demo app for any issue related to the demo app
  • 🔍 triage for issues not checked / read / managed yet, e.g. freshly-created issues
  • 🔨 tool for any issue related to tools, and they should not be reviewed by product owner, a11y team and design team
  • 👌 OK PO if the product owner validated the issue implementation
  • 👌 OK Accessibility if the a11y team validated the issue implementation
  • 👌 OK Design if the design team validated the issue implementation
  • ⌛ Waiting for validations if a pull request has beenr eviwed by the development team and the associated issue (which should be in *in review¨norad column) must be validated by the product owner, the a11y team and the design team
  • 👂 acessibility for issues related to accessibility
  • 🐞bug for issues related to bugs
  • 📀 token for any issue related to tokens
  • 🆕 feature for new features
  • ⚛ component for issues related to components
  • 🎇 module for issues related to modules
  • 📘 library for issues related to the Swift Package library and not the demo app
  • 📖 documentation for issues related to documentation

Use of pull requests

Each issue must have an associated pull request. The issue is "shared" with people who created it, bug reporter, product owner, design and a11y teams etc. They are more apropriate for discussions and notifications than pull requests. The pull request is dedicated to the development team ; expect no interaction from there is you are not part of the develoment team. A pull request which must not be merged as is and is not ready to be reviewed must be in draft mode. If a pull request has been reviewed, can be merged as is, but needs validation of product owner, design and a11y teams, a label "⌛ Waiting for validations" is added on it.

Validation process

Here is a Mermaid chart explaining how validation is done

flowchart TD
%% Nodes
    P("In purple, tasks for develoment team")
    Q("In blue, tasks for PO / a11y / design teams")
    R("In green, automated or CI/CD tasks")

%% Individual node styling.
    %% Purple - for development team actions
    style P color:#FFFFFF, fill:#AA00FF, stroke:#AA00FF

    %% Blue for PO, a11Y and design team
    style Q color:#FFFFFF, stroke:#2962FF, fill:#2962FF

    %% Green for automated tasks or CI/CD related topics
    style R color:#FFFFFF, stroke:#00C853, fill:#00C853
Loading 
flowchart TD
%% Nodes
    A("An issue is created")
    B("The development team moves the issue in 'In progress'")
    C("A draft pull request can be done")
    D("Implementation of the issue")
    E("Implemention done, pull request not anymore in draft mode")
    F("The development team makes code reviews")
    G{"Code review is OK ?"}
    H("Move issue in 'In review', mark pull request as 'Waiting for validations'")
    I("Make alpha build")
    J("Issue updated with build details")
    K{Request 3 reviews}
    L("Merge in develop branch")
    M("Nightly build (beta) with TestFlight and CI tags")
    N("Few days before end of sprint make release candidate tag")
    O("End of sprint, make new release, new tag, update issues with release details")

%% Edge connections between nodes
    A --> B --> C --> D --> E --> F --> G
    G -- NO --> D
    G -- YES --> H
    H --> I --> J --> K
    K -- OK PO --> L
    K -- OK accessibility --> L
    K -- OK design --> L
    L --> M --> N --> O

%% Individual node styling.
    %% Purple - for development team actions
    style B color:#FFFFFF, fill:#AA00FF, stroke:#AA00FF
    style C color:#FFFFFF, fill:#AA00FF, stroke:#AA00FF
    style D color:#FFFFFF, fill:#AA00FF, stroke:#AA00FF
    style E color:#FFFFFF, fill:#AA00FF, stroke:#AA00FF
    style F color:#FFFFFF, fill:#AA00FF, stroke:#AA00FF
    style G color:#FFFFFF, fill:#AA00FF, stroke:#AA00FF
    style H color:#FFFFFF, fill:#AA00FF, stroke:#AA00FF
    style I color:#FFFFFF, fill:#AA00FF, stroke:#AA00FF
    style J color:#FFFFFF, fill:#AA00FF, stroke:#AA00FF
    style L color:#FFFFFF, fill:#AA00FF, stroke:#AA00FF
    style M color:#FFFFFF, fill:#AA00FF, stroke:#AA00FF
    style N color:#FFFFFF, fill:#AA00FF, stroke:#AA00FF
    style O color:#FFFFFF, fill:#AA00FF, stroke:#AA00FF

    %% Blue for PO, a11Y and design team
    style K color:#FFFFFF, stroke:#2962FF, fill:#2962FF

    %% Green for automated tasks or CI/CD related topics
    style I color:#FFFFFF, stroke:#00C853, fill:#00C853
    style J color:#FFFFFF, stroke:#00C853, fill:#00C853
    style M color:#FFFFFF, stroke:#00C853, fill:#00C853
Loading
Clone this wiki locally