Your grade-level team agrees to build a common assessment so grading is fair and data is comparable across sections. Three meetings later, you've got a test that technically covers the standard, but it doesn't quite fit anyone's actual class — too easy for the honors section, oddly worded for the section with more multilingual learners, missing the specific vocabulary your own students spent two weeks building.
This happens because most teams design the common assessment the same way they'd design a single-class test: start writing questions, argue about which ones to include, land on something that's common mostly because everyone compromised equally, not because it was built well.
Start from the learning objective, not the questions
Before anyone writes a single question, the team should agree, in writing, on exactly what skill or objective each item is measuring. "Solve two-step equations" is too broad — does that include negative coefficients? Word problems? If the team doesn't nail this down first, you'll spend the writing session arguing about individual questions instead of building from a shared target.
Our [learning objectives tool](/learning-objectives) is useful here specifically because it forces a level of precision teams often skip when working from memory in a meeting — you can generate a set of graduated objective statements and use them as the actual anchor the team agrees on before anyone drafts an item.
Build the core together, leave room at the edges
The fix for the "flattens everyone's class" problem isn't to abandon commonality — it's to split the assessment into two tiers explicitly:
- The common core (70-80% of the assessment): identical across every section, measuring the shared objectives the team agreed to. This is what gets compared across classes.
- A flex section (20-30%): each teacher can swap in questions that match their own section's specific vocabulary, context, or challenge level, as long as it measures the same underlying objective at the same rigor.
This way the data comparison stays valid on the core, and no one's class is forced through wording or examples that don't fit their students.
Where teams actually break down
Rigor drift. One teacher's version of "same objective" ends up easier or harder than another's. Fix: draft one sample item together as a team, out loud, before anyone goes off to write their own flex-section items independently.
Scope creep in the meeting. An hour disappears debating one ambiguous question instead of building the structure. Fix: use the [assessment blueprint tool](/assessment-blueprint) to generate the full test structure — objectives, item counts, difficulty distribution — before the meeting even starts, so the team is reviewing and refining a draft, not building from a blank page together in real time.
Losing track of who agreed to what. Write the final agreed-on objectives and the common/flex split down in one shared doc immediately after the meeting, while everyone remembers the same version of what was decided.
Why this is worth doing well
A genuinely common assessment gives your team real, comparable data — which section needs more time on a concept, which teaching approach is working — without forcing every class into an identical shape that fits none of them well. That's the actual point of collaborating on assessment, not just splitting the writing labor evenly.
