Skip to content

Working Practices

Tim Johnson edited this page Jul 22, 2024 · 4 revisions

Introduction

This page is for describing "how our work works", i.e. the processes and procedures that help us manage our work efficiently.

Work Item Types

All work items are logged as GitHub Issues. We distinguish between the following types of work items.

Tasks

Used for most things, e.g. for developing an evolution of the product or documenting something. If during review or testing some rework is required in order to meet the ticket requirements then this work is done under the initial ticket (rather than raising a new bug ticket).

The User Story format can be used if helpful (as an X, I want Y, so that Z).

The INVEST mnemonic criteria gives further guidance.

Bugs

These are for raising issues that have been seen outside of the work being done on a particular task.

Definition of Ready

The following criteria must be met before an item of work can start.

For both tasks and bugs:

  • Ticket has been reviewed by the majority of the team

For tasks:

  • Has sufficient verifiable acceptance criteria
  • Has been estimated in terms of story points

For bugs:

  • Has reproduction steps if possible
  • Ideally is reproducible
  • Has expected behaviour
  • Has actual behaviour

Definition of Done

For all software changes:

  • Unit tested (100% coverage for new tickets)
  • Automation tests added (where practical)
  • Any relevant documentation updated

For all changes:

  • Peer reviewed
  • Independently reviewed as meeting the acceptance criteria

Expedited Tickets

Our focus is on finishing tickets before starting new ones, we pull new tickets from the Ready column once we've done everything we can against the in-progress tickets. (Minimising the number of in-progress tickets helps to reduce context switching).

The exception to this is when we have a ticket of sufficient priority to justify stopping current work partway through, for example to resolve an issue that is preventing users from using vAirify. These high-priority tickets are marked in GitHub as P0s (via the Priority field of the ticket). P0s are given priority over anything else and are discussed first during the stand-up regardless of where they are in the workflow.

vAirify Wiki

Home

Getting Started and Overview

Investigations and Notebooks

Testing

Manual Test Charters

Clone this wiki locally