| Lesson 1. Introducing Yourself in a Remote Product Team Meeting |
| You join Northbank Digital on a Monday morning. The team is distributed, the calendar is full, and you need to sound confident quickly. In this lesson you practise introducing yourself in a remote product team meeting, explaining what you work on, and signalling how you like to collaborate. You will also do a short baseline diagnostic: a mini stand-up update and a short written ticket comment, so you can see what is already strong and what tends to slip under pressure.
The model input is a realistic meeting snippet plus a follow-up Slack message. You will notice how B2 speakers keep their introductions clear without oversharing, and how they invite questions in a friendly way. You then build a small toolkit of phrases for role, responsibilities, and availability. Your end task is to produce two work artefacts: a 30-second spoken introduction and a short Slack post that helps the team know where to find you and what you are working on. |
| Lesson 2. Clarifying a Vague Feature Request with a Product Manager |
| Product has a request: “Can we make the dashboard faster?” At B2 level, the challenge is not understanding the words, but narrowing the request into something the team can build without guesswork. In this lesson you join a short kick-off call with Mia, the Product Manager, and you practise asking targeted questions that uncover the real goal, the user impact, and the success criteria.
You will work with a model dialogue where an engineer handles ambiguity politely, checks assumptions, and avoids sounding like they are blocking the work. You will build phrases for clarifying what “faster” means (latency, load time, throughput), and for confirming priorities and constraints. Your end-of-lesson artefact is a short written summary: a clear problem statement plus a list of agreed next steps and open questions to post in the ticket or meeting notes. |
| Lesson 3. Writing User Stories and Acceptance Criteria in Jira |
| After the call, the real work starts: the ticket. If the story is unclear, developers build the wrong thing, QA tests the wrong thing, and everyone loses time. In this lesson you take rough notes from Northbank Digital’s backlog and turn them into a clean Jira user story with acceptance criteria that a cross-functional team can follow.
You will read a short example ticket thread and notice what makes it actionable: clear context, precise wording, and testable outcomes. You will practise tightening vague phrases, adding edge cases, and separating “must-have” from “nice-to-have” in a diplomatic way. You will also practise writing a short comment that explains what changed and why, so the team does not need to guess.
Your artefact is a completed user story with 4–6 acceptance criteria plus a short Jira comment that confirms scope, assumptions and next steps. |
| Lesson 4. Agreeing Sprint Estimates and Risks in Planning |
| Sprint planning is where language and judgement meet. You need to be clear about what you can deliver, but you also need to stay collaborative when the room feels optimistic. In this lesson you join Northbank Digital’s planning call. The team reviews a small set of stories, and you practise talking about estimates, capacity and risk in a way that sounds calm and credible.
You will work with model planning lines such as “I think this is closer to five points because…” and “I’m worried about the dependency on…”. You will practise justifying an estimate, proposing a smaller first slice, and setting conditions for a commitment (“If we get the API contract by Wednesday, we can…”). The end-of-lesson artefact is a short planning summary message for Slack: what you committed to, what is at risk, and what you need from others to stay on track. |
| Lesson 5. Giving a Clear Daily Stand-up Update under Time Pressure |
| Stand-up sounds simple until you are tired, interrupted, or unsure what to prioritise. In this lesson you practise a daily stand-up update that is short, informative and easy for others to act on. The scenario: Northbank Digital has a busy sprint, QA has found a new bug, and you need to update the team without going into a long technical story.
You will listen to a model stand-up where the speaker uses a clear structure and signals uncertainty responsibly. You will practise phrases for progress, next steps, blockers, and requests for help. You will also practise recovering smoothly if you lose a word or get interrupted, so you keep your place and your tone.
Your artefact is a 45–60 second spoken stand-up update plus one short Slack follow-up message that captures your blocker and what you need from a teammate. |
| Lesson 6. Summarising Decisions in a Backlog Refinement Checkpoint |
| This is your midpoint checkpoint lesson: you bring earlier skills together and prove you can keep a team aligned. The scenario is a backlog refinement meeting where the conversation moves quickly: Product adds a new constraint, QA raises an edge case, and an engineer suggests splitting the story. Your job is to steer towards clarity and then capture what was decided.
You will review and recycle your core toolkit from Lessons 1–5 (clarifying questions, scope language, risk wording, meeting structure). You will practise key interaction moves: checking shared understanding, summarising live, and confirming owners and deadlines without sounding bossy. You will also practise writing a clean follow-up that others can skim.
Your artefact is a short meeting summary for Confluence/Notion style notes: decisions, action items, owners, and next check-in time. This is also your performance check to measure progress in clarity, tone and structure. |
| Lesson 7. Proposing Design Options in an Architecture Discussion |
| Now you move into higher-stakes collaboration: design decisions. In this lesson, Northbank Digital needs a change to the API that could affect performance and operational load. You join an architecture discussion with engineering, SRE and Product, and you practise proposing options, comparing trade-offs, and inviting critique without sounding uncertain or defensive.
You will work with a model discussion where speakers structure their points, use evidence, and keep the tone constructive. You will practise language for criteria (performance, reliability, security, maintainability, cost) and for responsible risk framing (“My concern is…”, “The trade-off is…”). You will also practise closing the discussion with a clear decision and next steps.
Your artefact is a short design note section (ADR/RFC style): options considered, recommendation, and risks to validate. The aim is clarity that travels well to colleagues who were not in the call. |
| Lesson 8. Writing Diplomatic Code Review Comments on a Pull Request |
| Code review is one of the quickest ways to damage trust if your English sounds blunt. In this lesson you step into a GitHub-style pull request at Northbank Digital. The code works, but there are questions about naming, edge cases and a potential performance issue. You need to comment in a way that is clear, respectful and easy to action.
You will read a short PR thread and notice how experienced reviewers separate blocking issues from suggestions, and how they ask questions without sounding accusatory. You will practise softening phrases, giving reasons, and proposing alternatives. You will also practise replying to feedback on your own PR: accepting changes, explaining trade-offs, or negotiating a different solution.
Your artefact is a set of 6–8 review comments plus a short PR description update (intent, scope, testing). The goal is to sound collaborative and precise, even when you disagree. |
| Lesson 9. Coordinating a Deployment with a Rollback Plan in Slack |
| Releases are often run through chat, with half the team multitasking. In this lesson you coordinate a deployment for Northbank Digital’s web app and API in a Slack-style channel. There is a small risk: one service has recently changed, and you need to make sure everyone understands the sequence, the checks, and the rollback plan.
You will work with a model chat thread that shows strong deployment communication: short messages, clear timing, and explicit ownership. You will practise announcing steps, requesting confirmations, and stating go/no-go criteria without sounding dramatic. You will also practise writing a brief release note line that is appropriate for the audience.
Your artefact is a deployment run message: step-by-step plan, risk call-outs, monitoring checks, and what to do if something goes wrong. The focus is clarity under time pressure. |
| Lesson 10. Leading Fast Triage in a High-Priority Incident Call |
| Now the pressure is real. An alert fires: parts of the platform are down for customers. In this lesson you join an incident call (war room) as the on-call engineer. Your job is to open the incident clearly, set expectations, and keep the conversation focused while people share partial information.
You will listen to a model incident call where the lead stays calm, assigns investigation threads, and avoids speculation presented as fact. You will practise language for impact statements, hypotheses, quick requests (“Can you pull logs around…?”), and escalation. You will also practise turn-taking moves that help in fast calls: interrupting politely, bringing someone in, and summarising every few minutes.
Your artefact is a short incident timeline note plus a clear initial incident message for the incident channel. The goal is to sound steady and organised, even when you do not have all the answers yet. |
| Lesson 11. Posting Calm Incident Updates for Stakeholders |
| During an incident, technical work is only half the job. The other half is communication that keeps trust. In this lesson you write stakeholder-safe updates for a live incident at Northbank Digital. You need to be factual, time-based, and clear about next steps, without overpromising or sharing internal speculation.
You will study two model updates: one written for engineers in the incident channel, and one written for non-technical stakeholders. You will notice how the wording changes: more detail for the team, more impact and reassurance for stakeholders. You will practise setting an update cadence, naming what is being investigated, and stating what users should do (if anything). You will also practise apologising appropriately: accountable but not dramatic.
Your artefact is a three-part update set: internal status, stakeholder update, and a short recovery message once service stabilises, including what comes next. |
| Lesson 12. Handling a Full Sprint Cycle in a Capstone Simulation |
| This final lesson is your capstone simulation. You run through a realistic mini sprint cycle at Northbank Digital, then deal with an incident that interrupts the plan. You will reuse your core language from the whole course: clarifying requirements, setting scope, making a planning commitment, giving a stand-up update, capturing decisions, writing a diplomatic review comment, coordinating a release message, and communicating calmly when something goes wrong.
The capstone is designed to feel like real work: limited information, time pressure, and changing priorities. You complete two attempts: first to see your natural habits, then again after a focused improvement checklist. Your performance check uses a simple rubric: structure, key information, tone, interaction moves, and clarity under pressure.
Your final artefact pack includes: a short requirements recap, one Jira update, one stand-up script, a meeting summary, one PR comment, an incident update, and a short postmortem paragraph with actions. This gives you templates you can keep using after the course. |
