Workflow

  3 minute read  

Basics

  1. Attend your teams daily stand-up. Here you will discuss work that was done yesterday, work remaining on the board to be done today, and any issues that might be blocking you
  2. Start working on an issue that has been assigned to you. If you do not currently have any issues assigned to yourself, review the existing issues on your teams board and start working on the issue with the highest priority.
    • If you are still unsure what to work on talk with your team
  3. Once you have an issue to start working on:
    • Make sure to move the issue along the board, or apply the ::In Progress label
    • Assign the issue to yourself
    • Continue to work on the issue until it is ready for review
    • If you find that the list of changes in the one issue is large, you should try to split it into smaller issues
    • Once everything is ready for review, open up a new Merge Request
      • Fill in the title and description, describing why the change is being made, not what is being changed
      • If the work in this MR completes the issue be sure to add Closes #{issueNumber} to make sure of Gitlabs automatic issue closing pattern
      • Assign yourself and the reviewers for the MR, this will normally be from your team but may need reviewers from other teams
      • Add any labels as required
    • Update the issue by moving it along the board, or apply the ::In Review label
    • During review it is possible that there will be comments left, go over the comments and address any feedback given
    • Once all the threads have been resolved and all approvers have approved the changes, the MR can be merged
    • If you cannot automatically close the issue then close it manually
  4. The team is responsible for making sure that any changes merged work correctly and does not introduce any new bugs.
    • Any new functionality should create new tests or update the current testing suite’s coverage to include the new functionality
    • Any new features or changes to the existing platform should have their own QA cards written or updated

You are responsible for any issues assigned to you. If there is anything you are unsure about or require help with reach out to your team, Iteration Manager or Product Manager. It is always better to communicate early rather than waiting.

Team Development Timeline

All the engineering teams work on a 2 to 4 week sprint or sprintlike environment. During this time the teams work on completing the epics that have been assigned to the team for the current sprint. This work may include development of a feature, fixing bugs, or starting investigation and break down of an upcoming feature.

Every second Monday the Release Manager will start a new release that will deploy any updates into the production environment. While the release is being tested automatically each team will also be performing their own tests in the UAT stack by performing the QA tests they’ve previously written on QA cards. Upon being prompted by the Release Manager, each team will write a list of new features, bug fixes or enhancements that will be compiled into release notes and distributed by the Release Manager. Once testing has been completed, the release will be promoted into production and the company will be informed of all the changes in the #announce-release-deployments channel.

Planning

At the start of every sprint the team will get together for a planning session. Here the engineers, engineering/iteration manager and product owners will discuss the work to be done during the next sprint.

Retrospective

At the end of a sprint teams will run their Team Retrospective to reflect on the last sprint and to collect any feedback that may need actioning in future sprints.