Project Update Templates
0 / 26 completed
1 / 26
Your project is on schedule and within budget. Which RAG status colour applies, and how do you open the weekly status email?
GREEN + formal status statement is correct. RAG status emails should:
- State the RAG colour explicitly — "Status: Green" — so stakeholders can scan quickly without reading the full update
- Use formal language — "progressing on schedule," "no impediments to report" rather than "all good" or "fine"
- "No issues" (Option A) and "All good!" (Option D) are too casual for a stakeholder status report
- Option C (Amber) would be incorrect if no issues exist — RAG should reflect reality, not caution
2 / 26
A dependency has delayed your API integration by 3 days. The project can still hit its final deadline if nothing else slips. What RAG status is appropriate?
AMBER is correct here. RAG definitions in project management:
- GREEN — on track, no known risks
- AMBER — at risk; a problem exists that could escalate, even if the end date is currently safe
- RED — the end date or scope is already breached or will be unless action is taken now
3 / 26
Which weekly status email structure is most useful for stakeholders who read updates on mobile in under 2 minutes?
The structured bullet format (Status + This week + Next week + Risks) is optimal for fast reading. Why this structure works:
- RAG status first — stakeholders know immediately if action is needed before reading further
- "This week" and "Next week" — show progress and predictability in parallel
- Risks section — even "None" is informative; its presence means you actively checked
- Long narrative emails (Option A) require effort to extract key facts
- Attachments (Option C) add friction — many stakeholders will not open them
- Slack (Option D) lacks the formal record that email provides
4 / 26
Your status is RED — the release date will slip by 2 weeks due to a critical bug found in QA. Which email opening is most appropriate?
Option B is correct. A RED status email opening must include:
- The status colour explicitly — "Status: RED" in the first line
- The revised date — "revised from 15 June to 29 June" — concrete, not vague
- The cause — "critical defect identified in QA on 22 May" — specific and factual
5 / 26
Which closing line best fits a weekly project status email sent to senior stakeholders?
Option C is most effective for senior stakeholders. It includes:
- Next update date — "Friday 30 May" — removes ambiguity about cadence
- Actionable request — "reply by Wednesday 28 May if you wish to raise agenda items" — gives stakeholders a clear path to influence
- Deadline for input — prevents last-minute additions to steering agendas
6 / 26
Sarah just submitted a PR with the following comment on your code review:
"This function could benefit from better error handling. Consider adding a try-catch block to gracefully manage potential exceptions and log them appropriately."
Which of the following responses would be most effective in replying to Sarah via Slack, updating the PR description, and informing the team about the next steps?
The key here isn't just acknowledging the feedback; it's demonstrating a proactive approach and initiating further discussion. Option 2 avoids conflict while still showing you received the comment. Options 1 & 4 are dismissive and don't progress the issue. Option 3 is the most constructive, requesting alignment on logging strategy – a common concern in development teams – and scheduling a follow-up to ensure everyone is on the same page. This shows collaboration and attention to detail, crucial for effective code reviews.
7 / 26
John: 'Okay team, just a quick update on the Phoenix API integration. We've hit a snag – the authentication service is intermittently failing, returning 503 errors. I've escalated to Ops, but it's impacting our ability to push out the new user onboarding flow. I'm marking this as Yellow for now.'
Which of the following responses would be most appropriate in a Slack message to respond to John and initiate a more detailed investigation?The correct answer focuses on actionable next steps and gathering crucial information: requesting logs and a timeline demonstrates proactive problem-solving and allows for effective prioritization. Options A and D are passive and don't address the immediate impact or need for investigation. Option B is overly positive without seeking specifics; it's important to manage expectations and understand the severity of the issue –
John is already taking appropriate action, so a supportive but focused response is best.8 / 26
The key here isn't just *that* logging exists, but *how* it's configured. A common misconception is that any logging is sufficient; however, production environments require careful consideration of log levels (to avoid flooding the system with debug information) and destinations (for efficient monitoring). Option 2 correctly identifies this need for specific configuration details—it's a critical element of robust code and demonstrates an understanding of operational best practices. Options A and D are completely inadequate, while option C is too verbose.
9 / 26
Alex just submitted a PR for a new feature that integrates with a third-party payment gateway. The PR description includes the following snippet:
"Implemented integration with Stripe. Handles credit card processing."
During a sprint review, your team lead asks you to refine this description to be more informative and actionable for other developers. Which of the following options would best improve the PR description?
The original description is far too brief. A good PR description should detail not just *what* was implemented (credit card processing with Stripe), but also *how* it was done. The incorrect options all miss this crucial element – specifically, the need to address potential issues like error handling, security, rate limits, and key API details which are essential for maintainability and understanding of the code. A more robust description would significantly reduce ambiguity and facilitate smoother collaboration.
10 / 26
Sarah just submitted a PR with the following comment on your code review:
"This function could benefit from better error handling. Consider adding a try-catch block to gracefully manage potential exceptions and log them appropriately."
Which of the following responses would be most effective in replying to Sarah via Slack, updating the PR description, and informing the team about the next steps?
The key here isn't just acknowledging the feedback; it's demonstrating a proactive approach and initiating further discussion. Option 2 avoids conflict while still showing you received the comment. Options 1 & 4 are dismissive and don't progress the issue. Option 3 is the most constructive, requesting alignment on logging strategy – a common concern in development teams – and scheduling a follow-up to ensure everyone is on the same page. This shows collaboration and attention to detail, crucial for effective code reviews.
11 / 26
John: 'Okay team, just a quick update on the Phoenix API integration. We've hit a snag – the authentication service is intermittently failing, returning 503 errors. I've escalated to Ops, but it's impacting our ability to push out the new user onboarding flow. I'm marking this as Yellow for now.'
Which of the following responses would be most appropriate in a Slack message to respond to John and initiate a more detailed investigation?The correct answer focuses on actionable next steps and gathering crucial information: requesting logs and a timeline demonstrates proactive problem-solving and allows for effective prioritization. Options A and D are passive and don't address the immediate impact or need for investigation. Option B is overly positive without seeking specifics; it's important to manage expectations and understand the severity of the issue –
John is already taking appropriate action, so a supportive but focused response is best.12 / 26
The key here isn't just *that* logging exists, but *how* it's configured. A common misconception is that any logging is sufficient; however, production environments require careful consideration of log levels (to avoid flooding the system with debug information) and destinations (for efficient monitoring). Option 2 correctly identifies this need for specific configuration details—it's a critical element of robust code and demonstrates an understanding of operational best practices. Options A and D are completely inadequate, while option C is too verbose.
13 / 26
Alex just submitted a PR for a new feature that integrates with a third-party payment gateway. The PR description includes the following snippet:
"Implemented integration with Stripe. Handles credit card processing."
During a sprint review, your team lead asks you to refine this description to be more informative and actionable for other developers. Which of the following options would best improve the PR description?
The original description is far too brief. A good PR description should detail not just *what* was implemented (credit card processing with Stripe), but also *how* it was done. The incorrect options all miss this crucial element – specifically, the need to address potential issues like error handling, security, rate limits, and key API details which are essential for maintainability and understanding of the code. A more robust description would significantly reduce ambiguity and facilitate smoother collaboration.
14 / 26
Sarah just submitted a PR with the following comment on your code review:
"This function could benefit from better error handling. Consider adding a try-catch block to gracefully manage potential exceptions and log them appropriately."
Which of the following responses would be most effective in replying to Sarah via Slack, updating the PR description, and informing the team about the next steps?
The key here isn't just acknowledging the feedback; it's demonstrating a proactive approach and initiating further discussion. Option 2 avoids conflict while still showing you received the comment. Options 1 & 4 are dismissive and don't progress the issue. Option 3 is the most constructive, requesting alignment on logging strategy – a common concern in development teams – and scheduling a follow-up to ensure everyone is on the same page. This shows collaboration and attention to detail, crucial for effective code reviews.
15 / 26
John: 'Okay team, just a quick update on the Phoenix API integration. We've hit a snag – the authentication service is intermittently failing, returning 503 errors. I've escalated to Ops, but it's impacting our ability to push out the new user onboarding flow. I'm marking this as Yellow for now.'
Which of the following responses would be most appropriate in a Slack message to respond to John and initiate a more detailed investigation?The correct answer focuses on actionable next steps and gathering crucial information: requesting logs and a timeline demonstrates proactive problem-solving and allows for effective prioritization. Options A and D are passive and don't address the immediate impact or need for investigation. Option B is overly positive without seeking specifics; it's important to manage expectations and understand the severity of the issue –
John is already taking appropriate action, so a supportive but focused response is best.16 / 26
The key here isn't just *that* logging exists, but *how* it's configured. A common misconception is that any logging is sufficient; however, production environments require careful consideration of log levels (to avoid flooding the system with debug information) and destinations (for efficient monitoring). Option 2 correctly identifies this need for specific configuration details—it's a critical element of robust code and demonstrates an understanding of operational best practices. Options A and D are completely inadequate, while option C is too verbose.
17 / 26
Alex just submitted a PR for a new feature that integrates with a third-party payment gateway. The PR description includes the following snippet:
"Implemented integration with Stripe. Handles credit card processing."
During a sprint review, your team lead asks you to refine this description to be more informative and actionable for other developers. Which of the following options would best improve the PR description?
The original description is far too brief. A good PR description should detail not just *what* was implemented (credit card processing with Stripe), but also *how* it was done. The incorrect options all miss this crucial element – specifically, the need to address potential issues like error handling, security, rate limits, and key API details which are essential for maintainability and understanding of the code. A more robust description would significantly reduce ambiguity and facilitate smoother collaboration.
18 / 26
Sarah just submitted a PR with the following comment on your code review:
"This function could benefit from better error handling. Consider adding a try-catch block to gracefully manage potential exceptions and log them appropriately."
Which of the following responses would be most effective in replying to Sarah via Slack, updating the PR description, and informing the team about the next steps?
The key here isn't just acknowledging the feedback; it's demonstrating a proactive approach and initiating further discussion. Option 2 avoids conflict while still showing you received the comment. Options 1 & 4 are dismissive and don't progress the issue. Option 3 is the most constructive, requesting alignment on logging strategy – a common concern in development teams – and scheduling a follow-up to ensure everyone is on the same page. This shows collaboration and attention to detail, crucial for effective code reviews.
19 / 26
John: 'Okay team, just a quick update on the Phoenix API integration. We've hit a snag – the authentication service is intermittently failing, returning 503 errors. I've escalated to Ops, but it's impacting our ability to push out the new user onboarding flow. I'm marking this as Yellow for now.'
Which of the following responses would be most appropriate in a Slack message to respond to John and initiate a more detailed investigation?The correct answer focuses on actionable next steps and gathering crucial information: requesting logs and a timeline demonstrates proactive problem-solving and allows for effective prioritization. Options A and D are passive and don't address the immediate impact or need for investigation. Option B is overly positive without seeking specifics; it's important to manage expectations and understand the severity of the issue –
John is already taking appropriate action, so a supportive but focused response is best.20 / 26
The key here isn't just *that* logging exists, but *how* it's configured. A common misconception is that any logging is sufficient; however, production environments require careful consideration of log levels (to avoid flooding the system with debug information) and destinations (for efficient monitoring). Option 2 correctly identifies this need for specific configuration details—it's a critical element of robust code and demonstrates an understanding of operational best practices. Options A and D are completely inadequate, while option C is too verbose.
21 / 26
Alex just submitted a PR for a new feature that integrates with a third-party payment gateway. The PR description includes the following snippet:
"Implemented integration with Stripe. Handles credit card processing."
During a sprint review, your team lead asks you to refine this description to be more informative and actionable for other developers. Which of the following options would best improve the PR description?
The original description is far too brief. A good PR description should detail not just *what* was implemented (credit card processing with Stripe), but also *how* it was done. The incorrect options all miss this crucial element – specifically, the need to address potential issues like error handling, security, rate limits, and key API details which are essential for maintainability and understanding of the code. A more robust description would significantly reduce ambiguity and facilitate smoother collaboration.
22 / 26
Maria comments on a PR: 'The response from the API is returning JSON, but it's missing the expected `userId` field. Can you add logging to capture this and investigate why it's not being included?' Which of the following best describes Maria's suggestion?
Maria's suggestion focuses on proactive debugging through logging. The core issue isn't just the missing field; it's a potential problem with data being transmitted correctly. The other options either misinterpret the situation or offer unhelpful advice – logging is crucial for understanding API behavior.
23 / 26
During a sprint planning meeting, David sends this Slack message: 'Hey team, just to update on the new authentication service. We're seeing intermittent timeouts (504 errors) when attempting to refresh tokens. Ops is investigating potential network issues.' What's the *most* important piece of information David has communicated?
While all options contain some data, David's primary communication is about the *frequency* of the 504 errors. This highlights a recurring problem and allows the team to prioritize investigation based on impact. Knowing the root cause (from Ops) would be beneficial, but frequency provides immediate context.
24 / 26
You're drafting a PR description for a change that adds support for two-factor authentication. The description currently reads: 'This commit implements 2FA.' Which of the following additions would create the *most* helpful PR description?
The original description is technically correct but lacks context and value. A good PR description explains *why* the change was made (security enhancement) and how it benefits users or the system. The other options focus on secondary benefits or technical details that aren't immediately relevant to reviewers.
25 / 26
During a daily stand-up, Sarah says: 'I'm working on optimizing the database queries for the reporting dashboard. I've identified several slow queries and am implementing indexes.' What is Sarah *primarily* communicating?
Sarah is focused on *how* she's addressing the slow queries – implementing indexes. This demonstrates her technical approach and provides a concrete update. While performance metrics and resource impact are important considerations, Sarah's initial communication centers around the chosen solution.
26 / 26
You receive this API response:
```json
{
"status": "error",
"code": 400,
"message": "Invalid request parameters: missing 'userId'."
}
```
What does this response *primarily* indicate?
The response clearly indicates that the *client* (your application) is sending an invalid request. The `code: 400` and `message` fields pinpoint the missing parameter – 'userId'. This allows you to correct the client-side code and resubmit the request.
Frequently Asked Questions
What does the "Project Update Templates | Coders Lingo" exercise cover?
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Project Update Templates | Coders Lingo"?
This exercise has 26 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Email & Writing exercises?
Browse the full Email & Writing hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.