4 exercises — internal Slack announcements, user-facing feature posts, CHANGELOG format, and external partner notices.
0 / 11 completed
1 / 11
You need to post a release announcement to your engineering Slack channel that your full team can understand. Version 2.4.0 ships a new payment retry logic and a security patch. Which announcement is best?
Option B is a complete internal release announcement with all necessary elements:
Internal release announcement structure: 1. Version + timestamp (UTC) — exact, unambiguous reference point 2. What shipped — per-feature with user impact described, not just technical description 3. Security items — call these out explicitly; include CVE ID and severity; note any active session changes 4. Deployment method — "blue-green, zero downtime" vs. "required restart" affects other teams 5. Affected services — relevant to on-call and integration owners 6. Monitoring links — what dashboards to watch, in #observability 7. Rollback procedure — version to roll back to + runbook link; not optional for production releases
Feature description pattern: Not "added retry logic" (what you did) but "failed transactions auto-retry up to 3×... reduces payment failure UX by ~60%" (what it means for users/business)
Security patch best practice: State the CVE, severity, and behavioral change (e.g., "active sessions invalidated on deploy"). Alert your support team if this triggers customer logins.
2 / 11
You're writing a user-facing feature announcement for the product website/blog. The new feature is an AI-powered code review suggestion tool. Which announcement tone and structure is most appropriate?
Option C is a professional user-facing feature announcement:
User-facing announcement principles: 1. Lead with the problem you're solving — "code review is valuable but time-consuming" — before describing the solution 2. Describe in user terms, not technical implementation — "analyses PRs and surfaces common issues" not "transformer model" 3. Concrete benefit list — specific, action-oriented: "suggests fixes, not just flags" — this is a differentiator worth stating 4. How to enable — precise path (Settings → Code Review → ...) — removes friction to adoption 5. Honest early access framing — "early access" + "we'd love your feedback" — manages expectations and invites engagement 6. No hyperbole — "incredible!" without substance is marketing filler; the what/why/how is what creates confidence
The "before and after" pattern: User-facing features land better when you describe the user's world before the feature and after. "Before: you caught issues in review; After: AI catches them before review" creates context that "AI review is here!" cannot.
Technical detail placement: Give a feedback or docs link for users who want implementation details, rather than including them in the main announcement.
3 / 11
You need to write a CHANGELOG entry for version 2.4.0 that includes a breaking change: the `/api/v1/users` endpoint is deprecated in favor of `/api/v2/users`. Which entry format is most useful?
Option B follows the Keep a Changelog format, the de-facto standard for developer-facing changelogs:
Keep a Changelog structure: • Version number + ISO date (YYYY-MM-DD) • Sections in a defined order: Breaking Changes, Added, Changed, Deprecated, Removed, Fixed, Security • Each entry: one line, specific, with PR or bug reference
Breaking change documentation requirements: 1. Mark it prominently — "Breaking Changes" section first, bold label 2. State the removal timeline — "will be removed in v3.0.0" — gives integration owners a window 3. Provide the migration path — link to migration guide — reduces support load 4. Name the deprecation signal — "will return `Deprecation: true` header" — enables automated detection
Why PR links matter in CHANGELOGs: When a bug is reported in 6 months, the PR link takes you directly to the commit, reviewer discussion, and context. "Fixed race condition [#BUG-201]" with a PR link is 5× more useful than a description alone.
What KeepAChangelog.com says to avoid: • Diff dumps — "changed 47 files" is not a changelog • Git log contents — commits are for engineers reading git, changelogs are for all audiences
4 / 11
You need to send an email to your external API partners about the v1 API deprecation. These partners are technical but not on your internal team. Which email is most professional?
Option B is a complete external partner API deprecation notice:
External partner communication requirements (higher than internal): Partners have different codebases, release schedules, and may not check your CHANGELOG or Slack. External notices must be: 1. Explicit subject line with action required + timeline — "Action Required" signals urgency; "Q3 2024" targets planning cycles 2. What's changing — specific endpoint path, not "some API stuff" 3. What they need to do — the exact migration path, what's functionally equivalent vs. changed 4. The timeline with milestones — three phases (header warning → body warning → removal) gives them windows to detect and respond 5. Migration guide link — not just "check the docs" 6. Support path — email or ticket; makes you reachable
Legal and SLA considerations: For enterprise partners with API SLAs, 6 months minimum notice for breaking changes is common. For public APIs, 12 months is standard practice. Always check your API agreement or ToS before choosing the removal date.
Response rate improvement tips: • "Action Required" in subject line significantly improves open rates • Follow up 30 days before removal with a second notice to integrations that haven't migrated (check via header/log analytics)
5 / 11
Alex from the QA team just flagged a critical bug in the latest release, 2.4.0, impacting user authentication. You need to quickly inform the development team about this issue and request them to prioritize a fix. Which Slack message is most effective for this immediate communication?
Option 1 clearly communicates the urgency and specific problem (authentication issue) within 2.4.0. It's direct and actionable. Options 2 & 3 are too vague and lack a call to action. Option 4 is just a general check-in - it doesn't convey the severity or request immediate attention.
6 / 11
Sarah, the lead developer, has written a code review comment on a pull request introducing a new feature: 'This function is overly complex and difficult to understand. Can you refactor it using a more modular approach?' Which of the following best reflects Sarah's intent and provides constructive feedback?
Option 1 acknowledges the comment but doesn't directly address Sarah's concern. Option 2 clearly states the issue (code complexity) and asks for a specific solution (refactoring). Options 3 dismisses the feedback entirely, while option 4 introduces an external authority without justification.
7 / 11
David from Product just sent you this message: 'Hey team, we're rolling out the new user profile update! Users can now upload a profile picture. Let me know if you have any questions.'
Which of the following is the MOST effective way to respond to David acknowledging the release and offering support?
'Sounds good, just push it to production.'
'Great news! What's the deployment process?'
'Thanks for letting us know – we're monitoring the rollout closely. Can I help with anything?'
'Profile pictures? That's a nice addition.'
The best response demonstrates proactive engagement and offers practical support. Option 2 directly asks about the deployment process, showing willingness to assist. Options 1 and 4 are too brief or dismissive. While acknowledging the release (option 3) is good, it doesn't immediately offer help; option 2 does.
8 / 11
You're writing a PR description for a new feature: implementing rate limiting on the API endpoint. The goal is to prevent abuse and protect server resources.
Which of the following descriptions best communicates this information to your team?
'Implemented new rate limiting.'
'Added rate limits to /api/v1/data to improve performance.'
'This PR introduces a mechanism to control access to the API, ensuring stability and preventing overload.'
'Fixed a bug related to API usage.'
A good PR description should clearly explain *why* the change was made. Option 3 explains the purpose (controlling access and preventing overload) which is crucial for understanding the impact of the code. Options 1 and 2 are too vague, and option 4 describes a bug fix, not a new feature.
9 / 11
Maria, a senior engineer, has posted the following comment on a pull request: 'The logic for handling user sessions is overly complex and tightly coupled. Consider using a dedicated session management library.'
Which of the following responses to Maria's comment would be MOST appropriate?
'Okay, I'll refactor it.'
'What session management library do you recommend?'
'I was going to use this approach…'
'Sounds good – let me know if you have any suggestions.'
Maria's comment offers a specific suggestion. The most appropriate response is to ask for clarification and guidance (option 2). This demonstrates that you're taking her feedback seriously and seeking actionable advice. Options 1 and 3 are too dismissive or defensive, while option 4 is simply acknowledging without engagement.
10 / 11
You're preparing a Slack message to announce the successful deployment of a new microservice, 'Phoenix.' The service handles asynchronous image processing.
Which message is MOST effective for informing your team?
'Phoenix deployed!'
'Phoenix is live – it's handling image processing asynchronously.'
'Just deployed Phoenix. Check the logs if you have any questions.'
'We finished deploying Phoenix.'
The best message clearly states what the service does and how it functions (asynchronous image processing). This provides context for your team to understand the impact of the deployment. Options 1 and 4 are too brief, while option 3 is less informative.
11 / 11
You need to draft a concise announcement about a critical infrastructure upgrade that will impact all services for approximately 30 minutes. This upgrade is essential for improving system stability and performance.
Which of the following statements is MOST suitable for communicating this information to your team?
'We're performing an infrastructure upgrade. Expect downtime.'
'Important: A scheduled maintenance window will occur, impacting all services between 10 AM and 1 PM today.'
'The servers are being upgraded – don't use any services during this time.'
'This is a routine system update.'
Providing specific details (time window) significantly improves communication and allows teams to plan accordingly. Option 2 clearly states the impact and timeframe. Options 1 and 3 are too vague, and option 4 downplays the importance of the upgrade.
What will I learn from the "Announcing Releases — Sprint Demo Exercise" exercise?
Practice writing release announcements: Slack release posts, user-facing feature announcements, CHANGELOG entries, and external partner notices. 4 intermediate exercises.
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 required.
How many questions are in this exercise?
This set contains 11 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this Sprint Demo & Releases exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss sprint demo & releases topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 11 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more Sprint Demo & Releases exercises?
See the full Sprint Demo & Releases exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.