A wrap is a structured, time-stamped record written by an engineer at the end of every shift that captures the current state of their work — what was completed, what's in progress, what's blocked, what decisions were made, and what the next shift should know. It's the async handoff standard for distributed teams.
The name comes from the idea of wrapping up a shift: before you close the laptop, you write a brief record of where things are. Explicit, structured, designed to be read by someone who wasn't there while you were working.
What a wrap is not
A wrap is not a standup update. A standup update is verbal, ephemeral, and typically brief — "I worked on X, I'll work on Y today, I'm blocked on Z." A wrap is written, persistent, and structured — it provides the specific detail that the standup doesn't: where exactly in X, what specifically in Y, what specifically about Z is the block.
A wrap is not a daily report for managers. It's a handoff record for the incoming shift. The audience is the next engineer who picks up the work, not leadership. This distinction affects what goes in it: a manager's report includes velocity and output; a wrap includes the interpretive layer that the next engineer needs — the decisions, the risks, the specific state of in-progress work.
A wrap is not a Jira comment. Ticket systems track task state. A wrap captures the engineer's live knowledge of the work, which includes context that lives outside any individual ticket: cross-cutting decisions, implicit risks, the rationale behind implementation choices.
What a wrap contains
A standard wrap has five sections:
- Completed: What was finished this shift, specifically. Not "worked on X" but "X is done, in this state, at this location."
- In progress: What is actively being worked on, described specifically enough that someone else could pick it up. Where in the codebase, what problem is being solved, what's done and what remains.
- Blocked: What is waiting on something external, and what it's waiting on. Explicit dependency, expected resolution.
- Decisions: Any call made this shift that affects what someone else will do, with brief rationale.
- For the next shift: What the incoming engineer needs to know before they start. Risks to watch, priorities to address, things not to touch yet.
Put a context layer under your distributed team.
StandIn gives engineers a 60-second wrap at the end of every shift. The next shift wakes up knowing exactly what to pick up — no standup required.
Request early accessHow wraps replace the standup
The daily standup exists primarily to transfer the state information that would otherwise be unavailable between sessions. When engineers write wraps consistently, the standup's information content is already captured before the meeting starts. The standup can then focus on real-time coordination — decisions that need immediate input, blockers that need collaborative problem-solving — rather than on status reporting.
Over time, teams with consistent wrap habits find that their standups get shorter, less tense, and more focused. Eventually, many eliminate the daily standup entirely and run a weekly sync for strategic alignment only.
Frequently asked questions
How long should a wrap take to write?
Three to five minutes on a typical day. Seven to ten minutes on a complex day with multiple decisions and blockers. If it's consistently taking longer, the format is too unstructured and the writing is becoming narrative rather than structured entries. The format should constrain the writing time, not just the reading time.
What if an engineer is interrupted and can't finish their wrap?
Write what you can before the interruption and complete it when you return. A partial wrap is better than no wrap, and an incomplete section with a note ("had to cut this short — see the PR comments for the session migration state") is better than a blank section that looks complete.
Should wraps be private or shared with the whole team?
Wraps work best when they're broadly accessible — anyone on the team who might work on the same code or in the same domain should be able to read them. Wraps don't typically contain sensitive information (personnel, compensation, legal). Broad access means any team member can self-serve context rather than asking, which reduces interruptions and builds shared understanding.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to eliminate your daily standup?
Distributed teams use StandIn to start every shift with full context — no standup required. Engineers post a 60-second wrap. The next shift wakes up knowing exactly what to work on.