Summarising Decisions in a Backlog Refinement Checkpoint.
English for Software Engineers and IT Teams. Lesson 6.
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.
1. Joining the backlog refinement meeting.
Today is your midpoint checkpoint, and we’ll keep it very real: you’re in a backlog refinement meeting at Northbank Digital. The conversation is moving quickly, and your job is not to be the loudest person in the room. Your job is to keep the team aligned. That means: you clarify what people mean, you summarise what’s been decided, and you make sure there’s an owner and a deadline for anything that still needs work.
In this first block, I want you to listen for three things: what the user story is about, what new constraint Product introduces, and what the team wants to do next. Don’t worry about understanding every single word. Focus on the decisions and the open questions. After you listen, you’ll write a short recap in one or two sentences, using calm meeting language like “Just to recap…” and “The open question is…”.
Scenario: fast refinement, multiple voices.
You’re on a video call with Product, QA, and another engineer. The ticket is already drafted, but people keep adding important details. This is exactly when teams lose alignment: everyone understands their own point, but nobody captures the shared plan.
In a refinement checkpoint, your English doesn’t need to be fancy. It needs to be structured and specific. In this lesson, you will practise capturing a fast discussion into:
Decisions (what we will do / not do)
Open questions (what we still need to confirm)
Action items (who will do what, by when)
Next check-in (when we’ll revisit)
Listen for the “shape” of the meeting.
When you listen to the short meeting excerpt in this block, try to catch:
What’s the story about? (one line)
What changed? (new constraint, edge case, or risk)
What’s the proposed next step? (split the story? confirm an assumption? update AC?)
Useful phrases you will reuse today.
Here are a few phrases you’ll use again and again across the lesson:
“Just to recap what we’ve agreed so far…”
“Can I check we’re aligned on the definition of…?”
“So the decision is…”
“The open question is…”
“I’ll capture this in the notes.”
These phrases do two jobs at once: they help the team, and they give you a calm, credible tone.
In the activity, you’ll write a short recap. Keep it short, factual, and neutral. No blame, no drama—just clarity.
Practice & Feedback
Listen to the meeting excerpt. Then write a short recap (2–4 sentences) as if you’re speaking in the meeting.
Include:
One sentence describing what the ticket/story is about.
One sentence stating the new constraint or edge case.
One sentence stating the immediate next step (for example, “we’ll split the story”, “we’ll confirm X”, “we’ll update the acceptance criteria”).
Use at least two phrases from the list on the screen (for example, “Just to recap…”, “So the decision is…”, “The open question is…”). Keep the tone calm and collaborative.
2. Checking alignment and definitions in real time.
Now let’s zoom in on a key micro-skill in fast meetings: checking alignment without sounding like you’re challenging people. In refinement, misunderstandings often come from one small word: “faster”, “done”, “in scope”, “minimum”, “consent”, “trial user”. If you let those words slide, you can end up with two different versions of the same ticket.
So what we’ll practise here is how to ask for definitions and success criteria politely. You’re going to see a short written excerpt from the meeting notes-in-progress, and you’ll notice how a good facilitator uses softeners like “Can I check…?” and “Just to confirm…”, and then paraphrases back the agreement.
After that, you’ll answer a few targeted questions and write one clarifying question of your own. Keep it practical: you’re trying to reduce ambiguity, not to win a debate.
The alignment move: define the terms before you commit.
In refinement, people often speak in shortcuts because they assume everyone shares context. Your job is to slow down just enough to make the meaning explicit.
Notice the difference:
Vague: “Let’s make onboarding faster.”
Aligned: “When we say ‘faster’, are we optimising load time, or the number of steps? And what target are we aiming for?”
At B2 level, you don’t need complex grammar here. What you need is polite precision.
A mini script you can reuse.
Here are patterns that work well when the conversation is moving quickly:
“Can I check we’re aligned on the definition of…?”
“When we say [term], do we mean… or…?”
“Just to confirm, the minimum for this sprint is…?”
“So the success criteria would be…”
Model excerpt: how the facilitator keeps clarity.
Read the short excerpt below. It’s written like quick notes / live typing during the call.
Pay attention to two things:
The facilitator asks a question without sounding negative.
The facilitator paraphrases the answer into a simple, skimmable statement.
Your turn in the activity.
You’ll answer comprehension questions and then write one clarifying question you would ask next.
Tip: choose a question that protects the team from rework, for example about SSO behaviour, acceptance criteria, or what “minimum” includes.
Practice & Feedback
Read the meeting excerpt. Then do two things:
Answer the three comprehension questions in full sentences.
Write one extra clarifying question you would ask in the meeting to reduce ambiguity (about scope, acceptance criteria, SSO users, or the Legal constraint).
Keep your tone neutral and collaborative. Imagine you’re speaking on a call with Product and QA. Try to use at least one phrase from this lesson, such as “Can I check we’re aligned…?” or “Just to confirm…”.
Live notes excerpt (refinement).
Ticket: NB-214 Improve trial onboarding drop-off after Step 2.
Product (Maya): New constraint: Legal consent copy must be included before shipping.
QA (Rina): Edge case: SSO sign-ups skip Step 1; consent screen may not show.
Engineer (Tom): Suggest splitting:
Part 1 (minimum): show consent consistently (incl. SSO)
Part 2 (later): UX optimisation (copy + progress indicator)
Facilitator (you): Can I check we’re aligned on the minimum for this sprint? Sounds like consent consistency is the priority. The open question is the SSO path.
Comprehension questions.
What is the new constraint?
What is the QA edge case?
What does Tom suggest doing, and why?
3. Turning fast talk into decisions and open questions.
You’ve now got the basic content of the meeting. Next, we’ll practise the part that separates “I attended the call” from “I kept the team aligned”: capturing decisions and open questions in a way people can act on.
In a real refinement, several things can be true at once. For example: the team can agree on the minimum scope, but still have uncertainty about an edge case, and still need Product to confirm wording. If you put all of that under one messy bullet point, nobody knows what is decided and what is still unknown.
So in this block we’ll work with a simple sorting habit: label each point as either a decision, an open question, or a parked item. Then you’ll rewrite a few messy meeting lines into clean notes using the chunk bank: “So the decision is…”, “The open question is…”, and “Let’s park that…”.
The key skill: separate “decided” from “still unknown”.
When people skim notes, they want answers to three questions:
What are we doing? (decision)
What do we still need to find out? (open question)
Who will handle it, and when will we know? (action item + time)
If your notes mix these together, you create extra back-and-forth in Slack.
A practical template for live summarising.
Here is a simple structure you can use in the meeting:
“Just to recap what we’ve agreed so far…”
“So the decision is…”
“The open question is…”
“Let’s park that and come back to it if we have time.”
You’re not being bossy. You’re providing a service: you’re giving the team a shared record.
Example: messy notes vs clean notes.
Messy (common):
Need consent for onboarding and SSO is weird and maybe do copy and progress bar later.
Clean (useful):
Decision: Minimum for this sprint is consent shown consistently, including SSO sign-ups.
Open question: Where exactly should consent appear in the SSO path (which screen/step)?
Later (out of scope for now): UX optimisation (copy + progress indicator).
Your task.
In the activity, you’ll take several “raw” lines and rewrite them as:
2 decisions
2 open questions
1 parked item
Aim for short, skimmable sentences. If you can, reuse the ticket language and keep the tone neutral.
Practice & Feedback
You’ll see five raw meeting lines. Rewrite them as clear notes.
Write:
2 Decisions (start each line with “Decision: …”)
2 Open questions (start each line with “Open question: …”)
1 Parked item (start with “Parked: …”)
Keep each line to one sentence. Use calm, meeting-friendly wording. Where possible, reuse phrases from the lesson, such as “So the decision is…”, “The open question is…”, and “Let’s park that…”.
Imagine these will go into Confluence/Notion and people will skim them in 20 seconds.
Raw meeting lines (needs cleaning up).
Legal says we have to show the new consent copy or we can’t ship.
SSO users skip step one, so they might never see consent.
We should probably split it, because otherwise it’s too big.
For this sprint we only do the minimum, and later we can do better UX.
Not sure where the consent should live in the SSO flow, needs confirming with QA and Product.
Reminder phrases.
So the decision is…
The open question is…
Let’s park that…
4. Agreeing owners and deadlines without sounding bossy.
Once you’ve captured decisions and open questions, the next step is ownership. This is where many engineers feel awkward in English, because they don’t want to sound like they’re assigning work to other people. The trick is to frame it as coordination, not authority.
You can do that with language like: “Who’s the best person to pick that up?”, “Can we agree an owner and a deadline?”, or “I can take an action to… unless someone else is closer to it.” That gives people space to volunteer, and it still creates clarity.
In this block, you’ll practise a short chat-style interaction. Imagine the meeting has ended, and you’re in the ticket thread or Slack. You need to turn two open questions into concrete action items with owners and due dates. Keep it light, factual, and time-bound. This is one of the highest-value communication habits in international teams.
Ownership language that feels collaborative (not pushy).
Good coordination is not about telling people what to do. It’s about making work visible and time-bound so the team can plan.
In refinement, you often need to turn an “open question” into an action item. The best action items have:
a clear deliverable (what “done” means)
an owner (one person responsible for driving it)
a due time (even if it’s a rough checkpoint)
Phrases to assign work diplomatically.
Here are patterns that sound natural in a mixed seniority team:
“Who’s the best person to pick that up?”
“Can we agree an owner and a deadline?”
“I can take that, unless someone else is closer to it.”
“Would you be able to look into X and report back by Y?”
“Let’s set a quick check-in at [time/day] to confirm.”
Mini examples (Slack or ticket comments).
Example A (inviting ownership):
> Who’s the best person to confirm where consent should appear in the SSO path? If we can get an answer by tomorrow EOD, we can keep NB-214 moving.
Example B (taking ownership with an escape hatch):
> I can capture the updated acceptance criteria in the ticket. Rina, would you be able to sanity-check the SSO edge case by lunchtime tomorrow?
Notice the tone: it’s specific and time-based, but still polite.
Your simulation.
In the activity, you’ll write as if you’re messaging two teammates: QA (Rina) and the engineer (Tom). You’ll propose owners and deadlines, and you’ll keep the thread moving.
Practice & Feedback
Write a short chat-style message thread (6–10 lines) as if you’re in Slack after the refinement meeting.
Roles:
You = facilitator
Rina = QA
Tom = engineer
Goal: turn the open questions into action items. Include:
One message asking who can own confirming the SSO consent behaviour.
One message proposing a deadline/checkpoint (for example, “by tomorrow EOD” or “by 11:00 UK time”).
One message confirming what you will do (for example, “I’ll update the ticket with the split and notes”).
Use at least two phrases from the chunk bank: “Who’s the best person to pick that up?”, “Can we agree an owner and a deadline?”, “I’ll capture this in the notes.”
Context to use in your chat.
Ticket: NB-214 Improve trial onboarding drop-off after Step 2.
Decision: Minimum for this sprint is consent shown consistently, including SSO.
Open questions:
Where exactly should consent appear in the SSO path?
What is the exact Legal copy / final wording and when is it ready?
People in the thread:
Rina (QA)
Tom (Engineer)
Maya (Product) is busy, not in this thread right now.
Chunk bank reminders.
Who’s the best person to pick that up?
Can we agree an owner and a deadline?
I’ll capture this in the notes.
5. Drafting clean notes for Confluence or Notion.
You’ve done the hard thinking: you’ve separated decisions from open questions, and you’ve moved towards owners and deadlines. Now we’ll turn that into the written artefact people actually rely on: a short, skimmable meeting summary.
The main challenge is balance. If your notes are too short, people can’t act. If they’re too long, nobody reads them. At B2, aim for a tight structure with clear headings and consistent formatting.
In this block, I’ll show you a model set of notes for this exact meeting. As you read, notice how each bullet is written as a complete thought, and how action items include an owner and due time. Then you’ll write your own draft notes, but with a twist: I’ll give you some missing information, and you’ll need to choose wording that stays factual and non-dramatic. Think: “stakeholder-safe”, even though it’s internal notes.
What “good notes” look like in a fast-moving team.
Your notes are not a transcript. They’re an outcome document. Someone should be able to miss the meeting and still know:
what we decided
what changed in scope
what questions are still open
who is doing what next
when we’ll check in again
Suggested structure (simple, repeatable).
A clean format for Confluence/Notion:
Context (1–2 lines)
Decisions (bullets)
Open questions (bullets)
Action items (bullets with owner + due)
Next check-in (one line)
Language tips for notes that sound calm and credible.
Avoid emotional language: not “this is a mess”, not “we’re blocked badly”.
Be specific about time: “by Tue 15:00 UK” is clearer than “soon”.
Model notes (read and borrow the patterns).
As you read the model in the activity, notice how it uses consistent labels and includes the key meeting moments: Product constraint, QA edge case, and the decision to split.
After you read, you’ll write your own draft notes (short, but complete). Don’t worry about perfection: the goal is a first draft that the team can refine asynchronously.
Practice & Feedback
Read the model meeting notes. Then write your own draft for the same meeting in 120–170 words.
Your notes must include these headings:
Context
Decisions
Open questions
Action items (owner, due)
Next check-in
Use the situation from earlier: NB-214, Legal consent copy, SSO edge case, and splitting the story into Part 1 and Part 2. Keep the tone neutral and skimmable.
Try to reuse at least three chunk bank phrases somewhere in your notes (for example, “So the decision is…”, “The open question is…”, “Action item: …”).
Model meeting summary (example).
Context: Backlog refinement for NB-214 (trial onboarding drop-off after Step 2).
Decisions:
So the decision is to split NB-214 into two parts.
Part 1 (this sprint): ensure Legal consent is shown consistently for all sign-up paths, including SSO.
Part 2 (later): UX optimisation (copy + progress indicator).
Open questions:
The open question is where consent should appear in the SSO flow (which screen/step).
Confirm final Legal consent wording and readiness date.
Action items (owner, due):
Action item: QA to outline the SSO path + expected consent behaviour (owner: Rina, due: Tue 15:00 UK).
Action item: Engineering to update ticket split + draft AC for Part 1 (owner: you, due: Tue EOD).
Next check-in: 10 minutes in refinement on Wed 16:00 UK to confirm scope and AC.
---
Now write your own draft summary.
Use the same structure, but write it in your own words.
6. Performance check: final summary others can act on.
This is your performance check and your practical take-away. You’re going to produce the final version of the meeting summary that you could genuinely paste into Confluence, Notion, or a Jira comment.
Here’s what I’m looking for: it should be skimmable in under a minute, and it should reduce follow-up questions. That means clear decisions, clear open questions, and action items with an owner and a due time. It also means the tone stays neutral and professional: you’re documenting reality, not judging it.
To make this realistic, I’ll give you a short follow-up message from Product with one extra constraint about timing, plus a small clarification from QA. Your job is to incorporate those updates cleanly. Use the chunks you’ve practised: “Just to recap…”, “So the decision is…”, “Action item…”, and close with “If I’ve missed anything, please reply in the thread.”
Take your time, then write the final summary in one go.
Final deliverable: meeting summary that prevents rework.
In a high-performing engineering team, the best meeting notes do one thing: they turn talk into execution.
For this final task, you will write the full summary for the NB-214 refinement checkpoint, including two new pieces of information (a Product update and a QA clarification).
Success criteria (use this as your checklist).
A strong summary will:
Start with Context (what meeting, what ticket, why it matters)
Make the Decisions unmistakable (minimum scope, split story)
Capture Open questions as questions (not as vague statements)
Include Action items with (owner: X, due: Y)
State the Next check-in time and purpose
End with a polite invitation for corrections: “If I’ve missed anything, please reply in the thread.”
Wording patterns to reuse.
Try to include several of these in your final text:
“Just to recap what we’ve agreed so far…”
“Can I check we’re aligned on…?” (optional in notes, but useful if you include one alignment line)
“So the decision is…”
“The open question is…”
“Action item: … (owner: …, due: …)”
“Next check-in: …”
“I’ll update the Jira ticket with these changes.”
Your input data.
In the activity, you’ll receive the last two updates that came in right after the meeting. Your summary should reflect them accurately.
Aim for 160–220 words. This is long enough to be complete, short enough to be read.
Practice & Feedback
Write the final meeting summary (160–220 words) for the NB-214 refinement checkpoint.
Include the headings:
Context
Decisions
Open questions
Action items (owner, due)
Next check-in
Incorporate the two new updates in the resource text (Product timing constraint + QA clarification). Make sure your action items reflect the updated timing.
Use at least four phrases from the chunk bank across your summary. Finish with: “If I’ve missed anything, please reply in the thread.”
Write it as if you will paste it into Confluence/Notion immediately after the call.
Two post-meeting updates you must include.
Update from Maya (Product): Legal can review the consent copy on Wednesday morning, but the wording is unlikely to be final until Thursday 14:00 UK. She still wants Part 1 this sprint, but we should avoid rework by keeping the consent text configurable.
Clarification from Rina (QA): For SSO, the consent screen currently appears only on the account linking step. She suspects some users never reach that step. She can provide reproduction steps and screenshots.
Reminder: what was already agreed in the meeting.
Ticket: NB-214 Improve trial onboarding drop-off after Step 2.
New constraint: consent copy required.
Edge case: SSO flow may skip consent.
Proposal: split into Part 1 (consent consistency) and Part 2 (UX optimisation).
