Workflows

Jira manual – Sprint development and test procedures

Business and Tech boards

When a project starts the issues in Jira are divided into 2 boards: Business and Tech. The Tech board holds all the issues for the tech team for the development of the app. The business board holds all the rest – the issues for sales, marketing, administration, etc. As the company grows, the business board may be split into more boards.

The Business Board

The business board is a Kanban board (Trello being the most widely known example), where staff can add issues, and set deadlines. Issues are usually assigned to a specific person and labels on issues are used to group issues. You add an issue for the business board, by setting the component to Business.

In the Business board, we use the “Due date” field to set the deadline. When issues approach their deadline, Jira will move the issues from their group to a ‘high priority’ group at the top.

An issue scheduler is used to create recurring issues.

The Tech Board

The development follows the scrum model aiming for a release early and releases often model, and The Tech board is therefore divided into sprints, which are short periods with a specific feature or area of the app as the focus area within the sprint.

The tech board normally does not use due dates, and we rarely assign persons to issues, as the work is planned in sprints.

Sprints

We work in sprints, from Monday 9.00 to Monday 9.00 DK time. Each sprint length can be 1-4 weeks or monthly, usually a project starts with short sprint lengths, and increases sprint length as customers begin onboarding. The most common length is 2 weeks. The team manager and developer discuss issues at daily morning stand-up meetings and the team manager reviews with the CTO weekly.

When the developer starts work on an issue, the developer moves the status to ‘In progress’ and when completed he moves the issue to the status ‘Test’. Each workday morning after the stand-up meeting, the team manager reviews the issues in the test and changes the status to ‘approved’ or back to ‘In progress’.

If for some reason the team manager is unable to complete testing of all issues in ‘Test’ after morning meetings, the team manager might add issue links in the company “tech-team” channel, for CEO/CPO/CMO to test and move to ‘Approved’.

Issue status types

Todo: Ready for work. The developer starts issues by rank (not priority).

In Progress: Developers have begun work on an issue. If input is needed, he pushes to DEV.

Test: The developer is done, and has pushed the issue to TEST.

Approved: The team leader or project staff have tested the task/change and it is ready for production.

Done: The task has been pushed to PROD.

Important approved issues are pushed to PROD during the sprint. Monday around 9.00 DK time, all approved changes are pushed to PROD. Issues are set to ‘Done’ when pushed and when all approved issues have been pushed, the team manager completes the sprint and sends a link to the sprint report in the company’s Slack #tech-team channel.

Project staff checks issues done in the sprint report and informs customers/partners based on labels set and uses the done issues/features in marketing and sales material (newsletters, website, etc.).

Issues

New issues are created in the backlog with an issue type.

Issue types

Bug: An error or a wrong translation.

Idea: An idea for a new feature.

Story: A description of a new feature written in plain user terms. Describe what it is.

Task: Something to be done, described in technical terms. Describe how to do it.

Sub-task: Larger tasks must be broken down into sub-tasks.

Epic: A part of the system grouping related stories and tasks (ex. Frontend or UI/UX, Profile).

Test: Part of the system or feature that needs to be tested or something that is not understandable.

At the end of a sprint, the product owner (usually the CEO) and CTO agree on issues in the next sprint and CTO ranks the issues. Ranking can be done before each sprint, or many sprints in advance. As a very rough rule of thumb, there can be 1 story, 15 tasks, 10 bugs, and 5 tests in a 2-week sprint per developer.