---
name: analysing-student-work
description: Read this when you have more than one learner's work in front of you and the question is what to do about it. Use it when given a class set, assignment or quiz results, a mark sheet or response CSV, or when asked what a class got wrong, which items were poor, who needs intervention, or what to teach next. It produces a next teaching move with a built-in check, not a report.
---

# Analysing student work — responsive teaching

The point of collecting evidence is the decision that follows. The deliverable
here is what happens in the next lesson.

## What done looks like

```
CLASS: <n> learners · <assessment> · <date>

WHAT THE EVIDENCE SHOWS
  <findings, with numbers — "18/28 chose distractor C on Q4">

WHAT'S BEHIND IT
  <the misconception(s), in language a learner would recognise>

THE MOVE — next lesson
  Starter (<n> min): <specific activity>
  Then:              <specific activity>
  Check:             <the question that will tell you it worked>

DIFFERENT NEEDS
  Secure (<n>): <extension>   Group (<n>): <support, when>
  Individual (teacher-only names): <what each needs>

ITEMS TO FIX
  <items with poor discrimination or dead distractors, and why>

WHAT THIS EVIDENCE CANNOT TELL YOU
  <honest limits>
```

## Constraints

- **Wrong answers before scores.** The score distribution is nearly
  information-free; the pattern of *specific* wrong answers is the data.
- **Cluster by cause, not by surface error.** Six different wrong answers may come
  from one misconception. `references/error-taxonomy.md` sorts them into slip /
  misconception / gap / misread-the-task / not-attempted — five categories with
  five different responses. Reteaching a slip wastes everyone's time.
- **Findings carry numbers**, not impressions.
- **Every misconception is named in plain language**, never "struggled with X".
- **A check is built in** that will show whether the move worked.
- **Broken items are separated from genuine difficulty.** Roughly one broken item
  per assessment is normal, and a broken item's "findings" are noise.
- **No claim rests on fewer items than it can bear.** Five items cannot support a
  claim about an individual; one class cannot support a claim about a cohort.

## Reading the numbers

Run `scripts/item_analysis.py` on any set of objective responses — facility,
distractor frequencies, discrimination, and flags for items that are broken rather
than hard. `python3 item_analysis.py --help`.

**The single highest-value finding is a distractor a third of the class chose.**
That's a nameable misconception with an obvious response, and it's what turns a
set of results into a lesson.

Other patterns: facility above 0.9 means the item isn't diagnostic here; below 0.3
means check the item before concluding anything about the class; wrong answers
spread evenly means guessing, so go back further than you think; negative
discrimination means the key or wording is wrong, so don't act on the item at all.

Caveats to state every time: discrimination is unstable below ~30 learners — with
one class it's a hint, not a finding; item statistics describe behaviour *in this
group*, not quality in the abstract.

## Reading open responses

Don't score first. **Sort.** Read the whole set once without marking, then sort
into 3–5 piles by what each response *does* — narrates instead of explaining;
explains but no evidence; evidence but no link back to the question; secure. Name
each pile in a sentence a learner would understand: that sentence is your
whole-class teaching point. The biggest pile determines the next lesson. Pull two
anonymised extracts — modal error and secure — for a best-of-two starter.

Sorting is faster than marking and produces something you can teach from, which
marking usually doesn't.

## Choosing the grain of response

| Share of class | Response |
|---|---|
| More than about a third | Whole-class reteach and one feedback sheet. Not thirty comments |
| Roughly 10–30% | Targeted group during the next task while others extend |
| A handful | Individual feedback with a specific task |
| One learner, repeatedly, across unrelated topics | Not a topic problem. Flag prerequisites, attendance or access needs to the teacher — say "worth checking", don't diagnose |

## Working with connected data

If a Nurture server is available, go from the class down to the **actual
responses** — aggregate statistics hide exactly the distractor patterns you need.
Look across assignments to tell a topic problem from a persistent one, and read
learners' own reflections, which often identify the sticking point faster than the
work does. Discover the available tools rather than assuming names.

Session analytics can locate *when* comprehension dropped, but see the warning in
`eliciting-evidence` about treating engagement data as evidence of understanding.

## Privacy and proportionality

- Individual learners are named only in teacher-facing output. Anything shown to a
  class is anonymised.
- Never rank learners by attainment.
- Never infer ability, home circumstances, effort or character from results. Report
  what the work shows and stop.
- Don't carry a learner's data between contexts the teacher didn't intend.

## References

- `scripts/item_analysis.py` — item analysis from a CSV.
- `references/error-taxonomy.md` — the five error categories, how to sort a class
  set fast, the diagnostic questions to ask a learner, and what not to conclude.