Operating Procedures

Last updated: 30.11.2021 Editor: David Jenkins

Overview

As outlined in the Methodology section, the Wavumbuzi technical team adopts the Agile approach to project management, which breaks product development up into phases (cycles). To identify the focus for each phase and ensure effective implementation of the product design within that phase, the Wavumbuzi technical team typically operate within the following operating procedures:

Needs Analysis
Sprint Planning
Day-to-Day Execution
Feedback

Each of these procedures are fleshed out in greater detail below.

Needs Analysis (Populating the Feature Backlog)

The assessment of users needs is an ongoing process which is overseen by the Product Owner, who collects information from a variety of sources (including: research, user surveys and focus groups, reflections from in-country implementation teams, etc.) to sculpture the vision for the product. The Product Owner analyses the user needs and identifies the set of features that will satisfy these needs. This consolidated list of features forms the feature backlog.

In the Wavumbuzi JIRA account, features (or feature sets) are grouped into 'Epics', which each contain a set of 'tickets' that outline the requirements for that Epic. Tickets can either be defined as a "bug", a "task" or a "story" depending on the nature of the ticket.

- "Tasks" are typically administrative type tasks that are very defined and do not relate to a specific feature
- "Stories" typically detail a user need and relate to a new feature or 'epic' that is yet to be added to the system
- "Bugs" are typically errors that have been reported with the existing system

These Epics are regularly reviewed by the team and scoped (at a high level), before being assigned a time estimate to completion (from design > deployment) and a priority ranking.

Note 1:

Whilst the assessment of user needs (and the subsequent production of new epics and user stories in the feature backlog) is an ongoing process, we have found it helpful to schedule extended workshop sessions at the beginning and end of each sprint to allow for input into the feature backlog from the implementation team (and other key stakeholders - see the 'feedback section below), which may inform the relative priorities for the upcoming sprint phase.

Note 2:

Time estimates must account for time allocated for both scheduled and unscheduled work (e.g. problem solving, design, testing, bugs, etc.).

Note 3:

User stories are expected to follow the following standardised format: "As a < type of user >, I want < some goal > so that < some reason >."
Tickets should always be assigned to the 'epic' (or feature set) to which it relates to.
Tickets should always be assigned an 'assignee' and a 'reporter'. The 'assignee' will typically be assigned by the Product Owner, unless it requires special technical expertise, in which case it will be assigned by the lead developer (as per the Product Owners request). As a default, the reporter will always be assigned as whoever creates the ticket. If you are creating a new ticket, but you are not the Product Owner, you can assign the Product Owner as the 'assignee' with a note for him/her to reallocate as required.

2. Sprint Planning

Once 'Epics' and 'tickets' are scoped, they are prioritised by the Product Owner and scheduled into the upcoming 'sprint phases/cycles'. This gives the wider team an indication of what features/capabilities to expect and when they can expect them to be live on the system.

Each ‘sprint phase/cycle’ begins with planning and design, and will typically end with the release of a new feature or capability. The sprint plan for the current ‘sprint phase/cycle’ is reviewed and adjusted each week by the Product Owner as progress is realised and more accurate estimates are projected.

Sprint phases/cycles are typically either scheduled around key constraints, including budget cycles, challenge dates and holiday periods.

In planning the ‘sprint phases/cycles’, the Product Owner uses the JIRA Backlog to sort and prioritise 'tickets'. Those 'tickets' related to the upcoming sprint are moved into the Kanban Board for the attention of the development team, whereas those reserved for future sprints will remain in the JIRA Backlog.

3. Day-to-Day Implementation

To manage the day-to-day implementation of the plan for the current sprint phase/cycle, the team adopt the Kanban and Scrum frameworks.

Kanban Framework

The Kanban framework on the Atlassian software is delivered using a Kanban Board, which is populated with the 'tickets' prioritised for the current sprint phase/cycle. The board is structured into columns (steps). Tickets are prioritised on the board from top to bottom and right to left. Those items located on the top-most right position on the board are the highest priority items (unless they are in the 'Live On Production' column, which means they require no further action) and those in the bottom-most left position are the lowest priority.

Board Structure

The Kanban Board is broken down into eight columns which indicate the status of the tickets in that column. Tickets typically move from left to right across the board. Below is a breakdown of the current column structure of the Kanban Board, what the status is of tickets in the respective columns, and who is responsible for tickets populated in these columns.

Selected for Development

These are tickets that have been selected for development in the current sprint cycle and that are ready for developers to begin work on. This column is populated by the Product Owner.

In Progress

These are tickets that the development team are currently working on. There should be a maximum number of three tickets per developer in this column. This column is populated by the Developers, who pull across tickets from the "Selected for Development" queue as they begin work on them. This ensures that there is never more than one developer working on the same ticket at the same time, and helps the Product Owner track who is working on what tickets.

Review
- These are tickets that have been complete and are currently under "code review". This means that action taken to complete this ticket is being reviewed by a second developer to double check the logic and accuracy. This column is populated by the Developers, who pull across tickets from the "In Progress" queue as they complete them.
Merged to Development
- @Peace or @Ruti to define this status
Ready for Testing
- These are tickets that have been deployed to the testing environment and are ready for the QA team to test. This column is populated by the Developers, who pull across tickets from the "Merged to Development" queue as they are deployed to the testing environment.
Testing Failed

These are tickets that have been tested by the QA team and have been deemed to in some way fail to meet the specifications/ requirements detailed in the ticket. This column is populated by the QA team, who pull across tickets from the "Ready for Testing" queue as they are tested.

Ready for Production

These are tickets that have been tested by the QA team and have been deemed to fully meet the specifications/ requirements detailed in the ticket and that are ready to be deployed on the production environment. This column is populated by the QA team, who pull across tickets from the "Ready for Testing" queue as they are tested.

Live On Production

These are tickets that have been tested by the QA team, approved, and subsequently deployed to the production environment. This column is populated by the developers, who pull across tickets from the "Ready for Production" queue as they are deployed to the production environment.

Note:

Prioritising Unscheduled Work (Bugs)
QA > Link to Testing

Scrum Framework

To ensure that an analysis of user needs is occurring on a regular basis, that good communication and alignment is retained across the full project team, and that sprint plans and the Kanban board remains accurate and up-to-date, the Wavumbuzi team use the Scrum framework to manage their day-to-day operations and rhythms. These rhythms include:

Daily Update

This is a written update populated daily by the development team to share progress from the previous day's work, and blockages that require attention, and his/her priorities for the coming day. This rhythm helps ensure expectations are aligned across the technical team.

Format: Written update on slack "stand-up alice" channel
Frequency: Daily at 8am SAST
Agenda

What did you achieve yesterday?
What are you going to focus on today/tomorrow? (max 3x stories/priorities)
Are there any blockages hindering your progress?

Weekly Huddles

Format: Google/Zoom Virtual Meeting
Frequency: Monday, Wednesday and Friday at 8am SAST
Agenda

Celebrations for the previous week (review progress) [5 mins]
Demo progress (if possible) [5 mins]
Questions, blockages and problem solving (document lessons) [15 mins]
Set goals and priorities for the week [5 mins]

Sprint Planning Workshops

Format: Google/Zoom Virtual Meeting or In-Person
Frequency: As required (typically 2-3 workshops per year)
Agenda
Sprint Retrospective [30 mins]

Celebrations for the previous sprint (review progress) [5 mins]
Demo progress (if possible) [5 mins]
Identify any inefficiencies and solutions (document lessons) [10 mins]
Agree stories or bugs to be carried forward to next sprint [5 mins]
Review cost tracking spreadsheet [5 mins]

Sprint Planning [120 mins]

Review stories for the upcoming sprint [80 mins]
- Breakdown
- Agree on story design: (a) wireframe; (b) system configuration
- Assign estimations

Set internal goals/focus for the sprint [10 mins]
Review sprint scope and update roadmap [15 mins]
Prioritise stories in Kanban board [15 mins]

4. Feedback

Focus Groups

Surveys

Ratings Modules

Page updated

Report abuse