Agreements

Communication

• Response Time on Slack: 3 working hours.

• Response Time on Email: 2 working days.

• Let the client about the increased estimation of the task in advance (before the task is tracked more than expected).

• Integrate Jira notifications into Slack to reduce communications in Slack.

• It takes the developer no more than 1 hour of time to estimate the task. If more time is needed, it should be agreed with the client.

• NEW If a bug fix requires more than 1 hour, the developer and Project Manager must align on the estimated time before proceeding. Any additional hour of work should be approved in advance.

• Always ask/ inform the Saclab team before transferring anything.

• Never transfer on Friday unless the Saclab team asks you to do so.

Tracking tasks

• track communication into specific tasks.

• track scrum and other general meetings into specific tasks. Track time of team collaboration in specific tasks.

Workflow JIRA

1. Create task via JIRA tickets and confluence into PRODUCT BACKLOG (Product Owner). Create tasks using the name Epics and Stories in the confluence. Attach the confluence documentation to JIRA tickets.

2. Assign the task to a Project manager in column Estimation when task is ready to estimate with priority (PO). Let the PM know if you want this task added to the current sprint upcoming release.

3. Estimate task (PM + Dev team).

4. Add deadline to the task to SPRINT BACKLOG (Product Owner + PM).

5. Move task into TO DO phase (PM).

6. Move task into IN PROGRESS phase (Dev team).

7. Move task into CODE REVIEW phase with a link to Pull Request and comment if further clarification is needed for QA (Dev team).
   OR Move task into READY TO MERGE IN MASTER WITHOUT QA phase and assign PO (Dev team).

8. Move task into READY FOR QA phase (Dev team, code reviewer).

9. Move task into QA IN PROGRESS phase (QA).

10. Move task into TO DO phase if something is wrong, with comment (QA).

11. Move task into QA APPROVED phase and assign the PO if everything works well (QA).

12. Move task into READY TO MERGE phase and assign the Dev member (PO).

13. Move task into MERGED TO LIVE phase and assign QA (Dev team).

14. Move task into DONE phase and assign PO (QA).

15. Reopen the task from DONE to BACKLOG if needed (PO).

Release processes (SCRUM)

• Separate product backlog into 2-week sprints.

• Start sprints on Wednesdays. Finish on Tuesdays.

• Estimate tasks before starting the sprint (Refinement meeting every Monday).

• Calculate capacity and velocity for the current team.

• Have the plan and estimated tasks at least for the next 2 sprints.

• New requests can be planned for the next sprint or replace current tasks in the current sprint with lower priority. Current tasks from the current sprint will be moved to the next sprint. In case nothing moves – a decision is made to increase the length of the sprint or increase the team with approval for additional budget.

• Each change in the task’s descriptions (user stories, acceptance criteria) has to be reestimated.

• After deployment to production, the QA team has to check the checklist of all features. In case if will be found a critical bug the code need to revert, then fix it and make a new pull request. In case if revert is impossible or we can make a hotfix very fast – revert is not needed.

• Demo meetings in the end of the sprint on Tuesday (STAGE) to get approval to update the LIVE.

Release processes (KANBAN)

• Estimate tasks before starting work.

• Calculate capacity and velocity for the current team.

• Each change in the task’s descriptions (user stories, acceptance criteria) has to be reestimated.

• After deployment to production, the QA team has to check the checklist of all features. In case if will be found a critical bug the code need to revert, then fix it and make a new pull request. In case if revert is impossible or we can make a hotfix very fast – revert is not needed.

• Demo meetings in the end of the sprint on Tuesday (STAGE) to get approval to update the LIVE.

• In case we have tickets ready for merge, we are preparing them to release on Tuesday or Thursday. Befor merge in production we need to have final code review from Tech lead.

NEW! Bug reporting and charging

1. [Hotfix+] – reproduction of the bug on live, the fix of which is paid for by the client.
   Identification:
   – there is no scenario or criteria that describes in the initial scope;
   – the bug is not related to the scope of the current or previous sprint.

2. [Hotfix-] – reproduction of the bug on live, the fix of which is not paid for by the client.
   Identification:
   – there is a described scenario or criteria that is not work;
   – the bug is related to the scope of the current or previous sprint.

3. If the time spent on the task and fixing the problem [Hotfix-] is within the estimated time of the original task, the time spent on the task and solving the hotfix is paid in full.

4. If the found bug [Hotfix-] goes beyond the estimate, then everything that is tracked above the task estimate is not paid by the client.

Hotfix description:

1. Ticket type. Set the type of ticket – bug.

2. Ticket name. Use text [Bug] for the [Hotfix-] at the beginning of the ticket name (it will be easier to separate hotfixes in tracker report).

3. Link to the scope. Add related link to the documentation or another ticket, which describes the initial scope with the scenario and criteria.

4. Description in the bug report. Provide information about which scenario or criteria was not met (criteria number or item of the initial task). Add Actual result with steps to reproduce, video or screenshot and Expected result.

GIT Flow (not finished description)

1. Get the code from the master.

2. Develop features.

3. Deploy to STAGE using CI/CD settings.

4. Collect all the features for the sprint and deploy them all together to the LIVE.

5. Hotfix has to be deployed to Stage env, after developing merge to master.