📄 Engineering Sprint Workflow
Sign in

Engineering Sprint Workflow

Abstract

This guide outlines the standard workflow for engineers working on tickets within a sprint, ensuring clarity and smooth collaboration between Engineers and Consultants.

TL;DR

  • 🚀 Start: Pick the highest priority ticket in "To Do" and move it to "Doing."

  • 🧱 Blocked?: Move the ticket to "Design" and notify the Consultant immediately.

  • ✅ Done?: Record proof, create a Pull Request (PR), and move the ticket to "Internal QA" for the Consultant.

  • 🔄 Review: Address any feedback from the Consultant or PR Reviewer. PR Review should only happen after consultants approve the evidence provided.

  • 🏁 Finish: Once approved, the ticket is tested on staging and moved to "Customer QA"

1. Before You Start: Ticket Priorities and Readiness

Your work is organized into sprints and assigned by the Sprint Facilitator. When a ticket is assigned to you, you become the official assignee.

You must always work on tickets in the following priority order:

  1. Immediate

  2. Urgent

  3. Normal

  4. Non-Urgent

A ticket is ready to be worked on only when it is in the "To Do" stage.

❗️Warning/Important

❗ Definition of Ready: Before starting, ensure the ticket has clear requirements, an engineering estimation, and understandable test cases. If you're assigned a ticket that doesn't have an engineering estimation, you must immediately raise this to the Sprint Facilitator. If the test cases are missing or unclear, you must immediately contact the Consultant for clarification.

 ✍️ Note

Blocker Ticket Exception: Some tickets may be added to a sprint as "Blockers" to allocate time for investigation/future work to be done during the sprint. The goal of a blocker ticket is to define the requirements so it can become a standard "To Do" ticket, or to simply allocate time that will most likely have to be spent during the sprint.

2. The Development Cycle: From 'To Do' to 'Internal QA'

​a. Start Work: "Doing"

​When you begin working on a ticket, immediately move it from "To Do" to "Doing". Ensure the ticket always has the correct assignees (the working engineer, PR reviewer(s), and consultant(s)).

​b. Handling Blockers

​If you encounter an issue that stops your progress:

    1. Immediately notify the Consultant.

    2. Move the ticket to the "Design" stage.

​The Consultant will work to resolve the blocker. Once resolved, they will move the ticket back to "To Do", and you should resume work based on its priority.

​c. Submit for Review: "Internal QA"

​Once development is complete, follow these steps to submit your work for review.

​Submission Checklist:

    • Functional proof recorded (video/screenshots).

    • Pull Request (PR) created.

    • Slack message sent to Consultant and PR Reviewer.

    • Ticket comment added with all links.

    • Ticket moved to "Internal QA" and assigned to the Consultant.

🧐 Example 

Example Slack Message: "Hi ConsultantName and PRReviewerName, the ticket Ticket−123 is ready for review. 

Ticket: Linktoticket PR: LinktoPullRequest Proof: Linktovideo/screenshots


3. The Review Process: Collaboration and Quality Checks

Your part of the work is now paused while the review takes place.

1. Consultant Functional Check

The Consultant reviews your video or screenshots against the ticket's requirements.

  • If Approved: They assign the ticket to the PR Reviewer for the technical review.

  • If Rejected: The Consultant will move the ticket back to "To Do" and assign it back to you with feedback. 

❗️Warning/Important

You must provide new functional proof when resubmitting.

2. Technical Code Review

The PR Reviewer inspects the code. A Pull Request (PR) is a request to merge your new code into the main project codebase.

  • If Changes Are Needed: The ticket is moved back to "To Do" and assigned back to you. Address the feedback and resubmit. In this case, no new video is required, but you are responsible for thoroughly re-testing your changes.

  • If Approved: The PR is merged, which deploys the code to the staging environment (a test environment that mirrors the live one). The ticket is then assigned back to the Consultant for final testing.

4. Visual Workflow: Sequence Diagram

This diagram illustrates the complete ticket lifecycle, including all review and blocker paths.