General Project Management Workflow

Overview

This workflow is good for:

• Small and middle size projects.
• Ready and standardized software, for example, Magento, Shopify.
• For the development or daily support and improvements.

Benefits:

• very easy to understand even for non-technical person
• rapid entry threshold, understanding of the development process

Possible customization:

• integration with different software (notifications, monitoring) by Trello power-ups
• workflow/columns can be changed based on client business needs
• In the workflow,  more roles can be involved

Roles & Duties

Business Manager or Customer Service Manager

• accounting
• client success management

PM

• project management
• working communication with the client

Tech Lead

• code review
• deploy
• technical consultation
• assistance to the developers
• technical assistance to the client

Dev

• development
• estimation

QA

• testing
• systems monitoring

Issue Lifecycle

Basic Trello board structure:

1 column:

“INFO” – here we put all the necessary information or links about the project and create in it tickets.

2 column:

“Proposed” – in this column, we add tasks that the client would like to offer, but will be done after the client approval.

3 column:

“MageDirect Backlog / Bug” – we put new tasks in it, which were received from the client or added by the client, or bugs from the QA engineers. To transfer tasks from column 3 of the “MD Backlog / Bug” to the 4 column “Scheduled” is entitled only to PM.

4 column:

“Scheduled” – a column with tasks available for development. From it, the developer takes tasks into development.

5 column:

“Work In Progress” – a column with tasks that are under development.

6 column:

“Code Review (For Techlead)” – when the developer has completed the task, he makes a pool request and sends it to the “Code Review (For TechLead)” column, which makes it possible for tech leads to understand that it is possible to upload the task to the test site. To transfer tasks from the column “Code Review (For TechLead)” to “After Code Review (For Dev)” has the right only for those tasks.

7 column:

“After Code Review (For Developer)” – when tech lead has checked and uploaded the task, it moves to the column “After Code Review (For Dev)”, then the developer who worked on the task checks it on the test site, and, if everything is good at checking, sends it for testing and transfers it to the column – MageDirect Initial QA Testing.

8 column:

“MageDirect Initial QA Testing” – the first column for testing. It says that the task is ready for verification on the site.

If the task has been tested and has some minor errors, it moves to the column #9.

9 column:

“MageDirect Regressive QA Testing” – column #9 contains tasks that have been verified by the QA engineer.

If the task has an error in column #8, we close the task and move it to the column #9, but create the task with an error. We put it in column #3 “MD Backlog / Bug”, and add the links to the current task and the task with the bug to the parent / child task.

If the task is not completely fulfilled, then the QA engineer has the right to transfer it to column #5 “Work In Progress”, add a comment to the developer and PM. Errors on the task should be placed in the description of the task with the note: “Bugs”

10 column:

“MageDirect QA Approved” – tasks after re-testing, which are ready for display to the client.

Columns 11-12-13-14 – Customer columns: {project name} – QA Testing / {project name} – QA Approved/Launched/Closed [!E]

After starting the project, we use additional columns:

• Ready to deploy
• Recently deployed.

They go after the client checks. In the ready-to-deploy-column, the client places tickets when he asks for the task to be uploaded to the main site, with the appropriate comment. The task on the main adds only tech leads. After adding, that lead carries the task to the Recently deployed column and writes the appropriate comment for QA to check the task on the main.

Additional columns on the project (we add if it is necessary):

– “POST LIVE TASKS” – tasks that we do after launching the project

– “New” – new tasks that were not originally included in the project

– “Need to clarify – {project name}” – tasks that we send for clarification to the client

– “{project name} QA Questions” – tasks that the client returns to us for clarification

Rules for creating cards on the project:

Example:

[Product page] [DMB] Need to create the gallery on the product page

When creating a card we use:

1) Belonging to a part of the site, for example: [Product page] – product page

2) Type of task to be performed

Abbreviation:

[B] – backend task

[D] – frontend task Desktop

[M] – frontend task Mobile

[DB] – frontend task Desktop + backend task

[BDM] – frontend task Desktop + frontend task Mobile + backend task

[MB] – frontend task Mobile + backend task

[Bug] – bug

3) The name of the task, written in the imperative mood and clearly describes part of the task

Note: on all projects, a necessary condition is: use labels. They share:

1) belonging to a part of the site and consistent with [Product page]

2) belonging to the task type and corresponding to – mobile / desktop / backend

3) Since we use not only development on our boards, we add DEV to our cards

Rule keeping the card:

1. The description of the task is added only to the description of the card. Be sure to include links to the design / avocode / psd / screens if necessary
2. Comments to the task are added in the comments, but they do not give the right to develop.
3. A necessary requirement: if someone asks for clarification in the comments, he must transfer it to the task description

A necessary requirement when moving a task from a column to a column is the use of rules:

1. The developer is obliged to write in the task comment a brief instruction for checking the task
2. The QA engineer must leave brief comments about the testing of the task
3. Those leaders are obliged to leave a comment about uploading the task to the site.

Communication & Documents

Communication channels

All questions related tickets – Trello

General questions about development stage  – Slack Channel

Organizational questions, accounting, и т.д – Slack private channel (to whom it concern)

Fixing arrangements – Email

Project documentation- Google Drive