Choose the most effective phrasing for reporting progress, estimates, and status in 5 real scenarios.
Progress update formula: status + specifics + timeline
Status: on track / behind / at risk / complete
Specifics: what you did, what you've produced
Timeline: when it will be done — specific date or relative (EOD, tomorrow morning)
Caveat: add only if there's a real risk — don't hedge everything
0 / 5 completed
1 / 5
You've completed about 60% of a task that was estimated at 3 days. You're now at the end of day 2. Which progress update is most professional and informative?
Why B is the model answer: honest, specific, with a revised estimate
A great progress update is:
Quantified: "60% through" — gives the team a mental model
Self-aware: "expected to be at 67% — slightly behind" — shows you're tracking against your estimate
Committed: "tomorrow afternoon — EOD at the latest" — gives a specific window
Compare to the alternatives:
A: Zero information — tells the team nothing
C: Vague optimism — "almost done" without a time is unreliable
D: Identifies the problem but gives no estimate or context
Progress vocabulary:
"I'm on track to finish by [date]."
"I'm slightly behind — I'll need [X more hours/days]."
"I've completed [X] and have [Y] remaining."
"My revised estimate is [date] — here's why it changed."
2 / 5
Your task is taking longer than expected because you discovered unexpected complexity during implementation. How do you communicate this professionally?
Why B is correct: explains the cause, gives a revised estimate, takes action
When a task takes longer than expected, the professional pattern is:
Name the task: "API integration"
Explain the cause specifically: "vendor's auth flow requires OAuth 2.0 with PKCE — not in original spec"
Give a revised estimate: "Thursday"
State your action: "I'll update the ticket"
This is not making excuses — it's providing the team with the information they need to plan. Unexpected complexity is normal in software development. The problem isn't missing the estimate; it's not communicating early.
Useful phrases for revised estimates:
"My original estimate was X. I've revised it to Y because [reason]."
"I discovered [unexpected thing] that adds [X time] to the task."
"I've hit unexpected complexity — I'll know more by [time]."
3 / 5
A sprint review is tomorrow and you have three stories: one complete, one 80% done, one not started. Your manager asks for a status update. Which is most appropriate?
Why B is the professional update: story-level specificity
This response goes story-by-story, giving the team everything they need:
Story 1: clear final status — "complete and merged"
Story 2: percentage, remaining work, specific timeline — "demo-ready by tomorrow morning"
Story 3: honest — not started; context — already flagged and moved with PO agreement
Sprint review vocabulary:
"Complete and merged" / "deployed to staging" / "demo-ready"
"Will carry over to next sprint" — use instead of "not done"
"Pending final review" / "in QA"
"Scope was adjusted — [story] was descoped with [PO]'s agreement"
4 / 5
During a daily standup, your team lead asks: "Are you on track for the end-of-week deadline?" You're not sure — there's a risk but you haven't confirmed it yet. What is the most honest and professional response?
Why C is the correct answer: honest uncertainty with a plan
Saying "yes" when you're not sure misleads the team. Saying "no" when you haven't confirmed the risk creates unnecessary alarm. The professional approach:
Current status: "currently on track"
The risk: "flaky integration test environment" — specific
When you'll know: "by EOD today"
What you'll do: "flag it immediately if the deadline is at risk"
This is called risk transparency — surfacing uncertainty early so the team can plan. It's far better than a surprise on Friday afternoon.
At-risk vocabulary:
"This is at risk — I'll know more by [time]."
"I want to flag a potential risk: [issue]. It may or may not impact the deadline."
"If [condition] isn't resolved by [time], we should consider [mitigation]."
5 / 5
You finished all your sprint tasks ahead of schedule on day 3 of a 5-day sprint. How do you communicate this most professionally?
Why C is the model professional behaviour: communicate capacity and offer help
Finishing early is great — but going silent is a missed opportunity. The professional move:
Announce completion clearly: list what you finished
Signal capacity: "I have capacity for the rest of the sprint"
Offer to help: ask about backlog items or blocked teammates
This demonstrates team-first thinking — one of the most valued behaviours on engineering teams.
Capacity vocabulary:
"I have bandwidth for more work — what's the next priority?"
"Is there anything I can pull from the backlog?"
"Is anyone blocked that I can pair with?"
"I could help with [specific area] if that would be useful."