Skip to content
Ameen Abozaid
JNR-053

Team workflows

  • 5 Lessons
  • 2 h practice (estimate)
On this page 8 topics

Overview

Topics

  • Branching
  • pull requests
  • code reviews
  • issue tracking
  • agile basics

Learn first

2 h of practice (estimate)

Learning outcomes

  1. Follow trunk-based development or a short-lived branch workflow.
  2. Write PR descriptions that a reviewer can act on, and keep PRs small.
  3. Give and receive code-review feedback constructively.
  4. Break work into issues, estimate roughly, and participate in agile ceremonies.

Lessons

  1. 01Branching strategies
  2. 02Good pull requests
  3. 03Code review as reviewer and author
  4. 04Issues, boards, and agile basics
  5. 05Demo: a pull request from issue to merge

Lab and exercises

Lab

JNR-053-LAB1 · Team sprint

Outcomes: 1–4 · Time: ~2 h In groups of three, deliver two Shop features in a one-week mini-sprint with issues, PRs, and reviews, ending with a retrospective. Acceptance: every change merged through a reviewed PR; retro notes written.

Exercises (assessment: PR and review quality)

IDOutcomeTask
JNR-053-EX011Compare trunk-based development and long-lived branches for a team of five; recommend one.
JNR-053-EX022Write a PR template with five sections and fill it in for a real Shop change.
JNR-053-EX032Split a 1,500-line change description into three PR-sized changes.
JNR-053-EX043Rewrite three harsh review comments constructively.
JNR-053-EX053Review a peer's PR: one correctness comment, one test comment, one optional nit.
JNR-053-EX064Split the "checkout" feature into five issues with acceptance criteria and rough sizes.
JNR-053-EX074Describe what happens in planning, stand-up, review, and retrospective in one sentence each.
Show solutions
  • EX01 Trunk-based: fewer merge conflicts, faster feedback, needs good CI and feature flags. Long-lived branches: painful merges and late integration. Recommend trunk-based or short-lived branches.
  • EX02 Sections: Summary, Why, How tested, Risks, Linked issue.
  • EX03 Separate refactor, new feature, and tests/docs, each mergeable on its own.
  • EX04 For example "This is wrong" becomes "This fails for an empty list; could we handle it and add a test?"
  • EX05 Comments are specific, polite, and marked blocking or nit.
  • EX06 For example: cart totals, shipping rules, payment call, order confirmation, error handling; each with "done when ..." criteria and S/M/L size.
  • EX07 Planning: choose and size work. Stand-up: share progress and blockers. Review: demo finished work. Retro: improve how the team works.
  • Common mistakes (2,000-line PRs, style-only reviews) are assessed through the PR and review quality marking.

Quiz

Outcomes: O1 branching · O2 pull requests · O3 code review · O4 issues and agile.

A self-check for you: nothing is graded, saved or sent anywhere. Choose an answer, then check it. You can try again as often as you like.

  1. 1In trunk-based development, changes are merged to main:O1
  2. 2A downside of long-lived branches:O1
  3. 3A good pull request is:O2
  4. 4A PR description should explain:O2
  5. 5A reviewer should look first at:O3
  6. 6A constructive comment is:O3
  7. 7As an author, when you get a comment you:O3
  8. 8An issue should include:O4
  9. 9A retrospective is for:O4
  10. 10A board column order that fits a workflow:O4

Practical part

Seven exercises JNR-053-EX01 to EX07 plus the lab; assessed on PR and review quality. Pass: quiz 8/10, at least five exercises correct, every lab change merged through a reviewed PR, and retro notes written.

Common mistakes

2,000-line PRs; reviews that only nitpick style.

Assessment

PR and review quality (COM dimension).

Career relevance

The graduation gate requires a reviewable PR; collaboration (MID-066).

Type to search levels, phases, modules and lessons.