The Daily Loop

Your work is a loop, not a timetable. We deliberately don’t publish an hour-by-hour day — our specialists are shared across concurrent projects, so any schedule would be wrong by Tuesday. What doesn’t change is the cycle you run and the order you run it in.

This page owns the sequence. It does not restate the rules — every step links to the page that owns it. If a number or threshold appears both here and elsewhere, the other page wins.

flowchart TD
  S["Start of day<br/>clear your review queue"] --> P["Pull one item<br/>within WIP limit"]
  P --> V{"Meets Definition<br/>of Ready?"}
  V -- No --> BK["Comment, tag the BA,<br/>pull the next item"]
  BK --> P
  V -- Yes --> B["Build<br/>branch = work-item id"]
  B --> BL{"Blocked?"}
  BL -- Yes --> TL["Team lead — same day"]
  TL --> B
  BL -- No --> PR["Open PR<br/>small, self-reviewed, linked"]
  PR --> R["Review + green build"]
  R --> Q["Hand to QA<br/>with test notes"]
  Q --> D["Done — DoD met"]
  D --> P

The loop, step by step

1. Clear your review queue before you write code. An open PR blocks someone else’s work; your unstarted story blocks nobody. The reviewer SLA is same working day and Code Review is WIP-limited to ~1 per reviewer — both mean reviews happen first thing, not last thing. → Branching & Pull Requests

2. Pull one item — never past your WIP limit. Take from the top of Ready. In Dev is capped at 1–2 per developer. If you’re at the cap you don’t start something new; you go help finish something already in flight. → WIP limits per column

3. Check Definition of Ready before you start. If the story fails DoR, do not start it. Comment on the work item, tag the BA, pull the next ready item instead. Starting an unready story is where most rework and scope disputes begin — it feels helpful and costs a week. → Definition of Ready

4. Build in small, traceable steps. Branch feature/<id>-short-desc; commits reference #<id>. Keep the change small enough that a review is real rather than a rubber stamp — target ≤ ~400 lines. → Branch & commit naming

5. Blocked? Team lead the same day. Not at tomorrow’s standup. Standup surfaces blockers, it doesn’t resolve them. Put it on the work item as well — if it isn’t on the board, it isn’t happening. → Blocker escalation

6. Open the PR — read your own diff first. Self-review before requesting a review. Link the work item; say what changed, why, and how you tested it; screenshots for any UI change. Build must be green. One reviewer minimum — two for backend, security, or when the author is a junior. → What a good PR description has

7. Hand to QA with test notes, then finish. Tell QA what changed and what to look at. “Done” means the whole Definition of Done — merged is not done. → Definition of Done

Non-negotiables

Rule	Why
Never merge without an approval and a green build	Branch policy enforces it. Don’t go looking for a way around it.
The board matches reality before you log off	The board is the truth. A stale board turns standup into a guessing game.
A blocker goes to the team lead the same day	Held overnight, it costs a day nobody planned for.
Don’t start a story that fails DoR	The cheapest moment to fix a bad story is before it’s started.
Client questions go through the PM	One contact per client. An answer in a DM becomes a commitment nobody priced.
nit: means non-blocking — everything else blocks	Don’t guess which comments you have to act on.

Worked example — one story, start to finish

Monday 09:35 — Hamza opens the board. Two PRs are waiting on his review. He does both before touching his own work: one approval, one with a nit: and one blocking comment.

Monday 10:00 — Standup, 10 minutes. Yesterday / today / blockers.

Monday 10:15 — He pulls DW-412 “Refund a paid order” from Ready. He has one item In Dev, so he’s under the cap.

Monday 10:20 — DoR check. Acceptance criteria are written, but the refund response shape hasn’t been agreed with the frontend — that fails DoR item 4, dependencies identified. He does not start it. He comments on DW-412, tags Samaha (BA) and Kenana (Frontend Lead), and pulls the next ready story instead.

Monday 14:00 — Contract agreed and added to the work item. He moves DW-412 to In Dev and branches feature/412-refund-order.

Tuesday 11:00 — The payment provider’s sandbox rejects partial refunds. That’s a blocker. He posts it on the work item and tells Firas Darwish (Backend Lead) immediately — not at Wednesday’s standup. Firas routes it to the PM, because unblocking it needs the client’s provider account.

Wednesday 09:00 — Unblocked. Build continues.

Wednesday 16:30 — PR opened: 180 lines, work item linked, what/why/how-tested in the description. He reads his own diff first and fixes two things before requesting review. Author is a junior, so two reviewers: Bakri and Firas Darwish.

Thursday 10:00 — Approved, build green. He squash-merges and deletes the branch.

Thursday 10:05 — Moves DW-412 to QA with a note: “partial and full refund, sandbox provider, check the audit row.” Abdulaziz picks it up against the acceptance criteria.

Friday — QA passes, client signs off in UAT, DoD met. Done.

Four days, and the one day lost to the provider blocker was visible on day one instead of surfacing at the demo.

What a bad loop looks like

• Three stories In Dev, none finished.
• A PR open four days because reviews happen “when there’s time”.
• A story started before DoR, then re-scoped mid-build.
• A blocker first mentioned at the client demo.
• The board updated once on Thursday for the whole week.

Every one of these is the same failure — work started but not finished. WIP limits and the DoR gate exist specifically to make it visible while it’s still cheap.