What your marker is actually grading
Software engineering cases rarely lack facts — they drown in them. Tickets, standup notes, burndown charts, incident timelines, pull request threads. The graded skill is selection plus argument: which artifacts prove which claim, and where the evidence stops. A paper that says "the team struggled with technical debt" states a mood. A paper that says "the sprint reports show carried-over items rising across four sprints while velocity held flat, which the retrospective attributes to untracked rework" states a finding with an artifact behind it.
Structure still matters the way it does in every case study — situation, problem, analysis, options, recommendation — but the analysis section speaks a particular dialect: root cause instead of blame, trade-offs instead of preferences, and prevention instead of promises. The three sections below cover that dialect piece by piece.
Five agile artifacts, read as evidence
1. Sprint backlogs and burndown charts. These show rhythm, not just progress. Carried-over stories, mid-sprint scope changes and flat burndowns are patterns your analysis can date and interpret. 2. Retrospective notes. The team diagnosing itself in its own words — the strongest primary source most cases offer. Quote sparingly, cite properly, and connect each recurring complaint to a downstream effect the case documents. 3. Incident reports. Ready-made case studies inside the case: timeline, impact, cause, fix. They deserve their own structure (next section). 4. Definition of done and coding standards. Boring on paper, powerful in analysis — gaps between the written standard and the delivered work explain many quality problems the case reports. 5. Release notes and commit patterns. What shipped when, and how unevenly. Large, late merges landing before a release date is a workload story your paper can tell from the timestamps alone.
One caution: artifacts describe behaviour, not intent. "No one updated the board" is a fact; "the team didn't care" is an accusation with no exhibit. Keep your language on the observation side of that line and the paper stays professional.
The incident post-mortem, structured and built
When the case includes an outage, a failed release or a security slip, structure it as a blameless post-mortem — the format the industry actually uses. Five parts: what happened, impact, root cause, what worked, and prevention with owners. Fill the builder below with your case's facts (or draft the fields and print the skeleton); it assembles the section in the order markers expect.
Incident post-mortem builder
Nothing you type leaves your deviceCopy it into your draft, or download and edit. Fields left empty are skipped.
Trade-off tables: the honest way to argue build vs buy
Engineering recommendations live or die on trade-offs, and prose is a bad container for them — the third option always drowns. Put the comparison in a table, criteria as columns, then argue the row that decides the outcome. The example below is illustrative (invented figures, invented weights) to show the shape; your case supplies the real criteria.
| Criterion (illustrative weights) | Build in-house | Buy SaaS |
|---|---|---|
| Time to ship (40%) | Two quarters | Two weeks |
| Fit to core workflow (30%) | Exact | Good, with workarounds |
| Run cost over 3 years (20%) | Two engineers part-time | Subscription + integration upkeep |
| Exit risk (10%) | None | Vendor lock-in on order data |
"On the case's own priority — shipping before the Q3 window — buy wins the 40% criterion outright, so the recommendation is to buy, but to negotiate data export terms now, because exit risk is the one criterion the vendor cannot fix later. A build decision would only win back if the workflow fit were judged decisive, and the retrospective evidence for that is thin: the case shows no requirement the SaaS cannot meet."
Notice the pattern: weigh criteria first, let one row decide, then name the condition that would flip the call. That's the whole section — three sentences around a table.
Three quick checks on the vocabulary
Markers notice when terms drift. Tap an answer on each — wrong picks turn coral with the reason shown.
1. A blameless post-mortem asks…
Blamelessness targets systems and mechanisms, because naming a person ends the investigation too early.
2. Velocity is best used in a case study as…
Velocity is a local planning aid; papers that rank teams by it misuse the artifact.
3. "Definition of done" gaps explain quality problems by showing…
The gap itself is the finding — whether the standard needs rewriting is a separate, second-order question.
Evidence hygiene: six checks before submission
- Every claim about the team points to a named artifact
- Incidents are structured as post-mortems, not anecdotes
- Trade-offs live in tables; prose argues only the deciding row
- No blame language — mechanisms, not people
- Recommendations name owners and a review point
- Illustrative figures are labelled and kept out of case citations
For the wider engineering picture — civil, mechanical, standards referencing — the guide to engineering case studies continues from here. If your brief is really a report with a case attached, the case study report writing page explains how report conventions change the structure. And for the hardware-and-standards side of the same faculty, the electrical engineering case study tips translate the artifact habit into circuits and codes.
Sprint over? Paper still pending?
When the analysis is clear in your head but the words won't land on schedule, a quoted, deadline-bound writer can draft the case study while you keep the engineering judgement where it belongs.
Frequently asked questions
How many artifacts should I cite in the paper?
Enough to carry each claim and no more — typically three to five, each cited at the exact moment it proves something. A paper that quotes every artifact it was given reads like an archive, not an analysis.
Can I criticise the team's process?
Yes, structurally. Criticise mechanisms and incentives, not individuals: "estimates excluded review time" is fair game; "the lead developer estimated badly" is both unprovable and out of scope for a blameless reading.
What if the case contains no incident to analyse?
Then the post-mortem structure applies to any decision point: a failed release, a missed milestone, an architecture pivot. The five fields — what happened, impact, cause, what worked, prevention — fit any of those once you rename the section honestly.
How do I show engineering trade-offs without a table?
In prose, pair every option with its cost in the same sentence — "buying ships in weeks but locks in the vendor" — and name the deciding criterion explicitly. It works, but a compact table plus a deciding-row paragraph is clearer and easier to mark.
Should I include commit-level detail?
Only as aggregates. Timestamps and merge sizes support workload claims; individual commits rarely do. If a specific change matters, describe its review trail rather than pasting diffs into the paper.
Is the post-mortem builder going straight into your workflow?