Methodology

Project's Board Management

Currently there are 7 columns for ticket status:

• "Product Backlog",
• "Ready for Development",
• "Sprint Backlog",
• "In Progress",
• "Ready for Testing",
• "Testing",
• "Done",

Also there are 4 views:

• "Backlog",
• "Sprint Backlog",
• "Non-Sprint Development",
• "Bugs",

Ticket Flow

"Backlog" view provides info about general state of work, shows all tickets in the project.

"Sprint Backlog" is configured to show ticket in development's flow in scope of sprints. It can show what is currently in development and in testing during given sprint.

"Non-Sprint Development" provides non-standard view to show tickets flow, when there are no active sprints.

When ticket has been created, automation bot adds it to Product Backlog column. After that, project's management sets ticket's data to fulfill Definition of Ready and moves ticket to Ready for Engineering.

From "Ready for Engineering" column, DevTeam, during Sprint Planning sessions, creates scope for sprint and sets priority for sprint's scope.

When given developer starts work over given ticket, manual moving to "In Progress" column is required.

After finishing work on ticket, PR should be created. When PR is merged, automation bot will close ticket and move it to "Ready for Testing" column.

Depending on ticket's requirements, ticket should be move to "In Test" column to perform testing of the new value, or directly to "Done" (always fulfilling Definition of Done).

Quick memo about tickets states in board can also be found in board's ReadMe panel.

Sprint VS Non-Sprint Workflow

Depending on current DevTeam's assignment and agreement about project's workflow, there're some differences in project's development:

• When Sprints are active, all work is viewable only on "Sprint Backlog" view, "Non-Sprint Development" will not be used and Vice-Versa,
• When Non-Sprint Development is in progress, there will be no meetings, work of project's team will be fully asynchronous,

Definition of Ready

General:

• Ticket follows Ticket Types templates,
• Ticket has correct labels assigned,
• Ticket is not on "blocked" status,
• Ticket is possible to finish in single sprint (if Sprint workflow is active),
• There is sufficient description/screenshot to start work,

Definition of Done

• Control List on linked PR is fulfilled,
• Business requirements are all fulfilled,
• Manual Testing passed (if required by ticket type),
• Code Quality gate on SonarQube is passed (if required by project),
• Code Coverage on SonarQube is at least 70% (if required by project),
• Reviewer approval,

Tickets Types

For more details regarding content of tickets, refer to issue templates folder in repo.

Bug Report

This type is for reporting any errors for the howl app, also for reporting, that something is wrong with repo (eg. configs, etc.).

Feature Request

This type is for new ideas or planned work addition to backlog.

Enviroment Issue

This type is for adding work to backlog, that refers given work environment of the app, like bugs, that are only appearing in Prod and Local, but not on Testing, or configuration issues on machines, etc.

Refactor Request

This type is for requesting DevTeam to refactor some part of the code, no matter on what part of solution it's located.

Test Request

This type is for requesting manual testing on some environment (not Local).