Engineering Contacts & Sprint Workflow

Target: Engineering and Consulting departments.

This article defines clear points of contact for ticket estimations, PR reviews, and handling mid-sprint issues. Having well-defined responsibilities will improve communication between consultants and engineers, reduce blockers, and overall create a smoother collaboration between both departments.

1. Who to Contact?

The Tech Owner for each project can be found in the Systems app.

Rules:

• If an issue arises mid-sprint, contact the Tech Owner for the respective project.
• If the Tech Owner is unavailable, escalate to the Sprint Facilitator, who will delegate accordingly.

2. Ticket Estimation Guidelines

The Tech Owner is responsible for:

✅ Providing an estimate (time, complexity, dependencies).

✅ Offering guidance on how to approach the solution (modules, architecture overview) — not necessarily a detailed solution, but pointing in the probable right direction.

✅ Identifying gaps in the ticket before assignment — by reviewing the ticket and drafting a path for the engineer, potential gaps between the consultant and engineering side can be found before development begins.

✅ Ensuring proper ticket management:

• Moving the ticket to Internal QA after merging the PR.
• Ensuring the PR link and videos (if applicable) are attached to the ticket.

By involving the engineering team earlier in ticket writing and ensuring structured ticket management, we reduce misalignment, improve handoffs, and make onboarding into projects more efficient.

3. Pull Request (PR) Workflow

🔹 Video Demos are Mandatory

• PRs must include a short video demonstrating the feature or fix.
• The consultant must validate the functionality before the Tech Owner reviews the PR.
• The Tech Owner is responsible for merging only after consultant approval.
• We prioritize functionality first, technical details second — this ensures we’re delivering value faster.
• The PR video must showcase the test cases defined in the ticket, ensuring alignment with expectations.

🔹 When a video is not possible:

• The engineer and consultant must align on whether it's acceptable to proceed without a video.
• If the engineer and consultant agree that a video is not necessary, this decision must be clearly communicated in the ticket, Slack, or ideally both. The Tech Owner should have access to this information to ensure alignment and avoid misunderstandings.

🔹 Sprint Completion Criteria

A ticket is considered completed within the sprint when:

✅ The consultant has approved the video, OR

✅ The consultant and engineer have agreed that no video is needed and have clearly documented this decision in the ticket, Slack, or both, ensuring the Tech Owner has easy access to it.

Enforcing this will:

• Encourage consultants to improve the quality of test cases written for tickets.
• Ensure that videos showcase test coverage and expected functionality, focusing on delivering value.

Example Workflow:

1️⃣ Engineer completes the PR and records a demo video (or aligns with the consultant if a video is not feasible).

2️⃣ Consultant reviews the video (or alternative validation) and approves the functionality.

3️⃣ Tech Owner reviews the PR (code quality, best practices).

4️⃣ If both consultant and Tech Owner approve, the PR is merged.

4. Handling Mid-Sprint Issues

If a blocker or urgent request arises mid-sprint:

1. Contact the Tech Owner for that project.
2. If unavailable, notify the Sprint Facilitator for proper assessment and delegation of what needs to be done.

Goal: Avoid unstructured escalations and ensure issues are properly triaged before disrupting the sprint focus.

5. Example Ticket Breakdown & Engineering Estimation

6. Main Risks of this Setup

1. Tech Owner Overhead – Added responsibilities (ticket estimations/guidance, PR reviews and mid-sprint issues) may create bottlenecks, impacting engineers' planned 80% capacity.
2. Mid-Sprint Disruptions – Frequent escalations can cause context-switching and reduce sprint efficiency.