Skip to main content

General Information

This document describes how NDIP defines the scope of work and tracks project progress. Our approach is to have a continuous flow of work similar to Kanban method. The goal is to allow planning flexibility, have a clear and visual view of the current status, reduce cycle time, and continuously deliver NDIP to our users. Since we use GitLab in our work, we adapt our process to GitLab capabilities.

Planning​

Milestones​

We do not use iterations but do have milestones that are defined for the project in Resolution. So, we mirror these milestones in GitLab and decide on a high level what we want to be done by the milestone date.

Labels​

We create labels to distinguish types of work, i.e. devops, core, status, or a scientific workflow. The full list is here

Epics​

Next, we create GitLab epics. Unfortunately, our version of GitLab does not include epic groups, so we use a single level of GitLab epics for both features/epics and user stories in Agile terminology. That means that our user story can be quite large, as opposed to Agile ones which should be done in 1-3 days. So, also taking into account that our team members might work on multiple projects simultaneously, an epic can take weeks to months to finish.

Epics are created by Product Owner (Greg) together with Tech Lead (Sergey) and prioritized during planning sessions. Epics are written as user stories, with descriptions in the form As .. I want ... So that ... . Corresponding labels are set for the epic, including status::backlog. For each epic, there should also be an issue called "Epic review" (created using issue template epic_review). This "dummy" issue does not have any code (can belong to any project, e.g. to "Platform Documents"), and used to officially close the epic.

Issues​

To further split the work, we create multiple issues (tasks in Agile terminology) within an epic. Each issue must be assigned to a GitLab project (code repository) and should be small enough to be done in two days.
Issues are created by the team (usually by the developer who works on an epic). Corresponding labels are set for issues as well, including status::backlog.

Daily Work​

Epics and issues are visible to everybody on corresponding Kanban boards. We ask team members to update them daily with the actual status.

Picking up an epic and creating issues​

  • If you currently don't have an epic you are working at, please pick up one from the column Selected for Development and move it to the In Progress column.
  • Create issues (see the above section) for this epic. If you need help with that - talk to the Tech Lead or discuss that during status meetings.
    • Set Selected for Development status for all issues of the epic (makes sense, since we have this epic in work).
    • Set issue weight - an estimated complexity of the issue. Set it to a value between 1 (<4 hours to complete) and 4 (about 16 hours to complete).
caution

Please make sure not to create large issues that one cannot complete in one-two days (weight more than 4 ). Split the issue if this is the case.

Working with issues​

  • If you currently don't have an issue you are working on, please pick up one from the column Selected for Development and move it to the In Progress column. Create a branch for this issue (via GUI where the branch name is set automatically, or use the issue number in the branch name if you create a branch manually)
  • After the issue is finished, create an MR, move issue to To review column, or close the issue if it does not require a review.
caution

Please don't work on anything we have no issue for. This makes it difficult to plan work and can lead to delays in the project's progress.

tip

Multitasking considered to be an anti-pattern in Agile practices due to task switching overhead. So, try not to have more than one/two issues assigned to you in In Progress column.

Status meetings​

Due to the nature of our work and small team size, we do not make daily stand-ups (but asking to keep issue/epic boards up-to-date). Instead, we have a weekly status update meeting to review the boards and discuss the progress. Please make sure to update your issues before that meeting as well.