Stakeholder Communication

Why it matters

Many release crises come less from the defect than from the surprise: a sponsor who learns on launch day that an area was never tested, or a support desk that hears about a known issue from customers. Time also removes options: two weeks before a release, scope or people can still move; on release day only "ship with the risk" or "move the date" remain.

For the tester, information has value only if it reaches a decision before the decision is taken. A tester who raises problems early, with facts and options, is trusted and invited into planning; one whose news arrives late is seen as a gate that only says "not ready".

Who needs what, and when

A stakeholder is anyone who affects, or is affected by, the product and the decisions testing informs. Build your communication map from decisions, not from the organisation chart: for each stakeholder, note the decision they own, the information that decision needs and nothing more, the routine rhythm of updates, and the triggers that cannot wait for the next update.

Some teams first place stakeholders on a power/interest grid, a common project-management tool: high power (influence over the decision) and high interest means close involvement; high power and low interest, short summaries that keep them satisfied; low power with high interest, such as a support desk, regular information; and low on both, an occasional general update.

• List the quiet ones too: support, operations, security, marketing when a launch date is public, an external client.
• Derive the information from the decision: a sponsor deciding whether to launch needs residual risk and the cost of each option, not test case counts.
• Agree triggers in advance: a Blocker or Critical defect in a must-have feature, an environment down for half a day, exit criteria forecast to be missed.
• Agree who tells whom: the tester informs the decision owner; the product owner, not the tester, tells marketing or the client that a date moves.

Bad news early, with options

Raise a problem as soon as it is confirmed and you can describe its impact, not when the fix is known. Uncertainty is news too: "the estimate comes at 15:00" lets the owner plan, while silence lets them assume all is well. Many teams follow a "no surprises" rule: nobody accountable for a decision should first hear of a problem in a meeting or from a customer.

A status that stays green while the work underneath fails, which some teams call a watermelon status (green outside, red inside), usually grows from small delays that each looked too minor to report. Triggers agreed in advance make turning amber, the warning colour between green and red, a rule, not a judgement call.

Tell the owner of the problem and the owner of the decision first, in private, so that nobody is caught off guard in a status meeting. The testing mindset lesson covered tone; an escalation adds structure, so the reader can decide instead of redoing your analysis:

• Headline: what is at risk and which decision is needed, in one sentence.
• Facts: what you observed, the evidence and how sure you are.
• Impact in the reader's terms: users, money, date or reputation.
• Options with their cost and risk, including accepting the risk, and your recommendation marked as yours.
• Who must decide by when, and the time of your next update.

Choosing the format

The ISTQB Foundation syllabus lists the usual means: talking with the team and other stakeholders, dashboards, email and chat, online documentation and formal test reports, with more formal communication for teams split by distance or time zones. Choose with four questions: how urgent is it, does it need discussion, must it be on record, and how much time does the reader have?

• Talk first when news is urgent, bad or easy to misread; then confirm it in writing within the hour.
• Chat for quick coordination in the team; decisions taken there scroll away, so copy them to the record.
• Email or a written update for routine status and anything that must be on record: the status in the subject, the headline in the first line (some teams call this BLUF, bottom line up front). A one-page summary can go to a client as a PDF.
• Dashboards for trends readers check themselves; a dashboard never replaces telling someone that a problem affects them.
• Meetings for decisions that need several people: triage, the go/no-go and, in Scrum, the Sprint Review with key stakeholders. The Daily Scrum is an event for the Developers, not a stakeholder escalation channel.
• A decision log for accepted risks: what, who, when and why. Across time zones, give every deadline its time zone.

Try it: Markdown Formatter Try it: Word Counter Try it: Timezone Converter Try it: Markdown to PDF

Worked example: a Critical defect two days before launch

A grocery delivery app releases 3.8 on Thursday at 10:00, together with a marketing campaign. On Tuesday at 11:20 the tester confirms GR-214: when a card payment is retried after a timeout, loyalty points are deducted twice. Retest and regression after a fix take about a day, so the fix must land by Wednesday 10:00.

At 11:30 the tester calls the developer and the product owner together; at 12:15 the escalation below goes to the product owner and the release manager. The tester does not post in the company channel or write to marketing: the product owner owns the date and informs marketing and support.

• At 15:00 the estimate arrives: two days. At 15:30 the product owner chooses option B; the release manager informs the sponsor, and support gets a known-issue note.
• The tester logs the decision (redemption off in 3.8, fix in 3.8.1, product owner, Tuesday 15:30) and adds a test that the flag really hides redemption.
• At Wednesday's go/no-go nothing is new: every risk has already reached its owner.

To: Sara (product owner), Faisal (release manager)
Cc: Omar (development lead)
Subject: AT RISK - release 3.8 (Thu 10:00), decision needed by Wed 10:00

Release 3.8 is at risk: a Critical defect was found today and the fix
has no estimate yet.

Facts
- GR-214: when a card payment is retried after a timeout, loyalty
  points are deducted twice. Reproduced 4 of 4 times on build rc2.
- Affects every customer who pays partly with points and whose first
  payment attempt times out.
- The checkout developer will give an estimate today at 15:00.

Impact
- Customers lose points during the campaign; expect support tickets.
- After a fix: about 1 day of retest and checkout regression.

Options
A. Fix, retest and release on Thu as planned, only if the fix lands
   by Wed 10:00.
B. Release on Thu with points redemption switched off by a feature
   flag; fix in 3.8.1. Support needs a known-issue note.
C. Move the release and the campaign to Sunday.

My recommendation: decide after the 15:00 estimate; choose B if the
fix cannot land by Wed 10:00.

Next update: today 15:30, after the estimate.

Try it: Date Calculator

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020The definition of Scrum: its accountabilities, events and artifacts, including the Definition of Done that testing helps meet.
• Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024ISTQB's advanced syllabus on managing testing: test planning and estimation, risk-based testing, monitoring, metrics and reporting.