English for Software Engineers and IT Teams. Lesson 4.
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.
1. Joining the sprint planning call.
Today you’re joining Northbank Digital’s sprint planning call. The key skill here isn’t just “speaking more”, it’s sounding calm and credible while you make judgement calls in front of the team. In sprint planning, people often feel optimistic, and that’s exactly when clear language matters.
In this lesson we’ll stay in one situation from start to finish: a short planning call where the team reviews a few stories, agrees what can fit, and flags risk. Your outcome is practical: by the end you’ll be able to post a short Slack summary that states what you’re committing to, what’s at risk, and what you need from others.
In this first block, you’ll listen to a realistic planning snippet. Don’t worry about understanding every word. Focus on three things: what the story is, what the estimate is, and what the risk or unknown is. That’s the planning mindset: scope, size, uncertainty. Then you’ll answer a few quick comprehension questions so we’re aligned on the context.
Situation: Sprint planning at Northbank Digital.
You’re in a remote planning call with:
You: software engineer
Mina: Product Manager
Raj: Tech Lead
Lena: QA
The team is reviewing three stories for the next sprint. The pressure is gentle but real: Mina would love to include “just one more thing”, and Raj is trying to protect focus.
What “good planning English” sounds like.
At B2 level, the goal is not to sound certain all the time. The goal is to sound reasoned:
you give an estimate and a reason
you name the unknown (what you need to confirm)
you flag risk and dependency without drama
Notice the difference:
Too vague
Calm and credible
“It’s probably fine.”
“I’m reasonably confident, but the main unknown is the API behaviour under load.”
“This is big.”
“This feels bigger than it looks at first glance because we’ll need a data migration and backfill.”
“We can do it.”
“If we get the API contract by Wednesday, we can commit to delivery within the sprint.”
Listening focus.
In the short audio in this block, listen for:
The story being discussed (what change?)
The estimate (rough points or effort)
The risk/unknown (what could delay it?)
Don’t try to memorise. Just catch the planning signals: because, main unknown, dependent on, not comfortable committing.
When you’re ready, answer the questions below in your own words. Short answers are fine as long as they’re accurate.
Practice & Feedback
Listen to the planning audio once or twice. Then answer the questions in 3 short parts:
What feature/story are they discussing?
What estimate do they mention?
What is the main risk or unknown?
Write in full sentences, but keep it brief (about 40–70 words total). You’re practising the core planning habit: summarising scope, estimate and uncertainty. Use the language you saw on the screen (for example: “The main unknown is…”, “They estimate it at…”).
2. Justifying an estimate with clear reasons.
Now that the context is clear, let’s work on the most important planning move: giving an estimate with a calm justification. In many teams, conflict starts when someone says a number with no reason, because the number feels like a personal opinion. Your job is to turn it into a professional judgement.
In practice, that means you’ll use simple structures like “I’d estimate this at around X because…” and “This feels bigger than it looks at first glance.” Then you add one or two concrete reasons: extra components, unknown requirements, testing effort, migration work, or cross-team dependencies.
In this block you’ll read a short ticket-style description for the CSV export story. Then you’ll write what you would say in the planning call: your estimate and your reasoning. Keep it tight and engineering-realistic. You’re not writing an essay; you’re making a decision the team can act on.
From “opinion” to “reasoned estimate”.
When you estimate, you’re not trying to be perfect. You’re trying to be transparent about what you’re counting.
A useful pattern is:
Number (or range) + confidence
Because (1–2 reasons)
Unknown (what you need to confirm)
Here are model planning lines you can reuse:
“I’d estimate this at around five points because…”
“This feels bigger than it looks at first glance.”
“The main unknown is…”
“I’m reasonably confident we can deliver this within the sprint.”
Example: same idea, different quality.
Vague: “Maybe five?”
Credible: “I’d estimate this at around five points because we need backend pagination and a safe way to generate the file. The main unknown is whether our infra supports streaming.”
Ticket details to estimate.
You’re estimating Export to CSV from reporting dashboard.
To make it realistic, here are the constraints the team already knows:
Reports can be filtered (date range, region, product line)
Export should include the same columns users see in the UI
Some customers have very large datasets
The backend currently returns the report in pages for the UI
QA expects tests for:
special characters (commas, quotes, non‑Latin characters)
large exports
permissions (only authorised users can export)
Your goal.
Write 2–4 sentences you could genuinely say during planning:
state an estimate (points or “small/medium/large” is fine)
justify it with specific work items
optionally flag an unknown
Aim for calm, practical language. You’re helping the team make a good commitment, not “winning” the conversation.
Practice & Feedback
Read the ticket details below. Then write what you would say in the planning call to justify your estimate.
at least two reasons (for example pagination, permissions, file generation, QA edge cases)
one unknown or risk using “The main unknown is…” or “I’m slightly worried about…”
Keep the tone collaborative and calm, like a real sprint planning meeting.
Story: Export to CSV from reporting dashboard.
Goal: Users export the filtered report to share externally.
Notes:
Data volumes vary a lot by customer.
Backend already provides paginated results for the UI.
Export should match UI columns and filters.
Must respect permissions (only authorised users).
QA wants coverage for special characters and large datasets.
Open point: We haven’t decided between generating the file in memory vs streaming.
3. Flagging dependencies and conditions for commitment.
Next, let’s handle the moment that often feels uncomfortable: when you can’t commit unless something else happens first. Many engineers either sound too negative, or they over-promise. What you want is a third option: a conditional commitment.
A conditional commitment is very normal in planning: “If we get X by Wednesday, we can do Y within the sprint.” This keeps you helpful, but it also protects the team from hidden risk. The key is to be specific: name the dependency, give a timeframe, and explain what happens if it slips.
In this block you’ll listen to a short exchange where Product pushes for an earlier delivery. Your job is to respond with polite, clear conditions. Think: ‘I’m not comfortable committing as it stands’ plus an alternative path, such as a smaller slice or a decision we need today.
After the audio, you’ll write a short reply you could say on the call.
The planning skill: “Yes, if…”.
In sprint planning, saying “no” directly can create tension. But agreeing without conditions creates rework later. A strong middle ground is “Yes, if…”.
Use this mini-structure:
Acknowledge the goal
State the dependency / risk
Set a condition with timeframe
Offer a next action
Here are examples that sound professional:
“I get why it’s important. We’re dependent on the API contract being confirmed. If we get it by Wednesday, we can commit within the sprint.”
“I’m not comfortable committing to that as it stands. The main unknown is the infra support for streaming. Can we timebox a quick decision today?”
“The risk is that we discover a limitation, which could mean we need a different approach. If that happens, we may need to de-scope part of it.”
What to avoid.
Over-confident promises: “We’ll definitely ship by Friday.”
Blame language: “You didn’t give us the contract.”
Vague hedging: “It depends.” (Depends on what?)
Your situation in this story.
The team is still discussing CSV export. Mina wants a firm date; Raj wants the team to keep flexibility. You need to stay calm, explain the dependency, and propose a concrete next step.
In the listening, notice how the speaker keeps the tone neutral, even when pushing back. Your answer should do the same: clear conditions, no drama.
Practice & Feedback
Listen to the audio. Then write what you would say next on the call.
Write 3–5 sentences (about 80–120 words). You are the engineer. Your aim:
Acknowledge Mina’s goal (fast delivery)
Name the dependency and/or unknown clearly
Set a condition with a timeframe using “If we…, we can…”
Offer a next action (timebox, decide, split the work)
Use at least two phrases from the examples on the screen (for example: “I’m not comfortable committing…”, “We’re dependent on…”, “The risk is that…”).
4. Proposing a smaller first slice to reduce risk.
Let’s add a very practical tool for planning conversations: splitting the work into a smaller first slice. This is how you keep momentum without pretending the full scope is easy. Instead of arguing about the perfect solution, you offer a safe step one, and you make the next step conditional on what you learn.
In our CSV export story, a smaller slice might be: export up to a certain row limit, or export only for small datasets, or start with an asynchronous job and email link later. The important part is how you talk about it. You want language that sounds constructive: “Could we split this into a smaller first step?” and “If we include X, we may need to drop Y.”
In this block you’ll read three possible slices and choose one. Then you’ll write a short proposal that explains the trade-off and the benefit: lower risk, clearer testing, faster delivery. That’s how you sound like someone who can ship reliably, not just someone who wants more time.
When splitting is the best engineering answer.
Splitting a story is not “avoiding work”. It’s a delivery strategy. It helps when:
the story has a big unknown
the edge cases multiply
you need a meaningful outcome fast
The language move is polite and practical:
“Could we split this into a smaller first step?”
“So we’re committing to… and leaving… for later.”
Three realistic slicing options (CSV export).
Read these as alternatives you might suggest in planning:
**Option 1: Limit initial scope (fastest)
- Export supports up to 10,000 rows**.
Clear message if the dataset is larger.
Later: add streaming / background job for larger exports.
**Option 2: Background job (safer for large datasets)
**- Clicking export creates a job.
User downloads from a link when ready.
More moving parts, but reduces memory risk.
**Option 3: Same-day value, fewer edge cases
- Export only for one report type** first (e.g., “Monthly Revenue”).
Later: add remaining report types.
How to explain the trade-off.
A strong explanation has:
the benefit (deliver something useful)
the cost (what is out of scope)
the condition (what would unlock the next slice)
Example:
> “Could we split this into a smaller first step? I’m reasonably confident we can deliver an export up to 10,000 rows within the sprint. If we include unlimited exports, the risk is memory issues for large customers, which could mean we need a streaming approach. So we’re committing to the capped export and leaving full-scale exports for later.”
Your turn.
Pick one option and propose it in 3–5 sentences. Keep it balanced: helpful but honest about trade-offs.
Practice & Feedback
Read the three slicing options. Choose one option and write a short proposal you could say in sprint planning.
Write 3–5 sentences (about 90–130 words). Make sure you include:
One sentence proposing the split (use: “Could we split this into a smaller first step?”)
One sentence explaining the risk you’re reducing (use: “The risk is that…, which could mean…”)
One sentence clearly stating what you commit to now and what you leave for later (use: “So we’re committing to… and leaving… for later.”)
Keep the tone collaborative. You’re offering a path forward, not blocking the work.
Slicing options for “Export to CSV”.
Cap export at 10,000 rows for v1.
Implement export as a background job with a download link.
Support export for one report type first (Monthly Revenue), then expand.
Reminder.
Large customers have very large datasets. Infra support for streaming is still unconfirmed.
5. Chat simulation: negotiating scope and commitment.
Now we’ll move into a quick Slack-style simulation. This is where planning often continues after the call: someone posts a message, someone asks for clarity, and you need to keep the thread productive.
Your challenge is to combine everything you’ve practised: estimate plus reason, risk plus consequence, and a conditional commitment. The tone should be professional and neutral. No defensiveness, no blame, and no vague “it depends”.
In the thread you’re about to read, Mina is pushing for certainty, Raj is trying to protect the sprint, and QA is asking about edge cases. You’ll reply as the engineer responsible for the work. Aim for short chat messages, not long paragraphs. Think in chunks: one message to propose a slice, one to state the condition, and one to suggest the next action.
Treat this as real work: the team needs a clear decision so they can move on. After you write, you’ll get feedback and an upgraded version that sounds natural in Slack.
Slack planning threads: keep it crisp, keep it calm.
In chat, long explanations can look defensive. Instead, use structured short messages.
A reliable Slack structure is:
Position: what you think we should do
Reason: why (one key reason)
Condition / dependency: what must happen first
Next action: what you’ll do, or what you need from others
Useful chunks for Slack.
These are especially natural in short messages:
“This feels bigger than it looks at first glance because…”
“The main unknown is…”
“We’re dependent on… being confirmed.”
“If we get X by Wednesday, we can…”
“Could we split this into a smaller first step?”
“So we’re committing to… and leaving… for later.”
Mini-rubric for your messages.
When you write your reply, check:
Clarity: can someone act on it without asking you again?
Tone: calm, collaborative, not absolute promises
Specificity: named dependency + timeframe
In the activity below, you’ll see the thread so far. You will write your next messages as if you’re replying in that same thread.
Practice & Feedback
Read the Slack thread below. Then continue the conversation as you (engineer).
Write 3 short Slack messages, each 1–2 sentences (total 80–140 words). Use chat style (line breaks between messages).
Your three messages should achieve these goals:
Propose a split into a smaller first step.
State a condition for committing (use “If we…, we can…” with a timeframe).
Suggest a next action (timebox, decision, who needs to confirm what).
Try to reuse at least three phrases from the chunk list on the screen.
#sprint-planning
Mina (PM): Can we commit to CSV export in week one? The customer is asking for a date.
Raj (TL): I’m nervous about committing without knowing the approach for large datasets.
Lena (QA): Also, please don’t forget edge cases: special characters, permissions, and huge exports.
Mina (PM): Understood, but I need something concrete. What can we say we’ll deliver this sprint?
6. Posting your planning summary in Slack.
Let’s finish with the artefact you can genuinely reuse at work: a short sprint planning summary for Slack. This is the message that prevents confusion tomorrow. It tells the team what you’re committing to, what’s at risk, and what you need from others.
A great summary is not a transcript. It’s a decision-focused note. It should be scannable in ten seconds. That means clear headings or bullets, specific owners, and time-based conditions. If there’s a dependency, name it and say when you need it. If there’s risk, state the consequence: what could slip or what might be de-scoped.
In the resource for this block, you’ll get meeting notes from our story. Your job is to turn them into a Slack message that sounds calm and credible. Reuse the phrases you’ve practised: “We’re committing to…”, “The risk is that…”, “We’re dependent on…”, and “Next action…”. When you’re done, you’ll get feedback and a polished version you can compare with.
The end-of-lesson deliverable: a planning summary others can act on.
A planning summary is a professional skill because it reduces follow-up questions and stops accidental scope creep.
Your summary should answer three questions:
What did we commit to? (scope for this sprint)
What is at risk? (unknowns, dependencies, consequences)
What do we need next? (owners + next actions + timeframes)
A simple, reusable template.
You can copy this structure for real sprints:
Sprint planning summary (Stories + risks)
Committed: …
At risk / unknowns: …
Dependencies: … (needed by …)
Next actions: … (owner, due)
Model language to keep it calm.
Notice how these phrases avoid blame and avoid over-promising:
“I’m reasonably confident we can deliver this within the sprint.”
“I’m not comfortable committing to that as it stands.”
“The risk is that…, which could mean…”
“We’re dependent on… being confirmed.”
“So we’re committing to… and leaving… for later.”
What good looks like (mini-rubric).
When you review your own message, check:
Specific: clear scope, not just “CSV export”.
Time-based: dependency includes a date/day.
Actionable: someone else knows what they need to do.
Professional tone: neutral, collaborative.
Now take the notes below and write your Slack summary. Aim for clarity over perfection.
Practice & Feedback
Write a Slack planning summary message based on the meeting notes below.
Write 120–170 words. Use this structure:
Committed: (what you will deliver this sprint)
At risk / unknowns: (what could go wrong and the consequence)
Dependencies: (what you need from others, with a timeframe)
Next actions: (who will do what by when)
Make it scannable for the channel. Reuse at least four phrases from today (for example: “I’d estimate this at around… because…”, “The main unknown is…”, “We’re dependent on…”, “If we…, we can…”, “So we’re committing to…”).
Planning notes (CSV export story).
Story: Export filtered report to CSV from reporting dashboard.
