Openbook for Software Teams: Sprints, Standups and Shipping

A typical software team runs its work through four or five separate tools. Tickets live in Jira. Conversation lives in Slack. Specs live in Confluence or Notion. Retros happen in a whiteboard app someone pays for personally. Standups happen in a bot that posts into a channel nobody reads. Every one of those tools has its own login, its own notification settings, and its own idea of who is on the team.

Openbook takes a different approach. You create one space for your team and compose it out of rooms — each room a fully built app for one kind of work. A Kanban room for the sprint. A Check-in room for async standups. A Retrospective room for the end of the sprint. A Q&A room for the questions engineers ask each other over and over. Same members, same search, same notifications.

This guide walks through how to set that space up and how to run a real sprint cycle inside it, start to finish. Everything described here is a shipped Openbook feature — no roadmap items, no hand-waving.

Start from the Software template

You could build the space room by room, but you don't have to. Openbook ships 12 one-click space templates, and the Software template provisions and seeds the rooms an engineering team actually uses. Pick it when you create the space, invite your team, and you have a working setup before your first coffee refill.

A sensible composition for a software team looks like this:

Room	Type	What it's for
Sprint Board	Kanban Board	Backlog, sprints, the scrum board, story points
Daily Check-in	Check-in	Async standups, mood, blockers
Retros	Retrospective	End-of-sprint retros, actions, follow-through
Engineering Q&A	Q&A	The internal Stack Overflow
Docs	Docs	Specs, RFCs, design docs
Wiki	Wiki	Runbooks and reference in Markdown
Team Chat	Chat	Channels and DMs
Release Plan	Gantt	Date-driven planning across sprints
Status	Project Status	Async reporting for stakeholders
Metrics	Dashboard	Live numbers from the boards

You do not need all ten on day one. Start with the board, the check-in, and the retro room. Add the rest when the need shows up. Rooms are building blocks, not commitments — the whole point of Openbook's model is that a space contains exactly the apps your team needs and nothing else. If you want the full tour of what each room type does, read Rooms Explained.

One structural note before we go deeper: Openbook's hierarchy is Organization → Space → Room. Your company is the organization. Your engineering team (or each squad, if you're bigger) gets a space. The rooms live inside it. Each space has its own members, roles, and a customizable sidebar, so a squad's space feels like the squad's home, not a folder in someone else's system.

Run your sprint on the Kanban board

The Kanban Board room is a full agile tool, not a sticky-note simulator. It gives you four ways to look at the same work — board, list, tree, and timeline views — plus a backlog, sprints, a scrum board, and sprint insights.

Here's the working loop:

1. Capture everything into the backlog. Bugs, feature requests, tech debt — it all lands in the backlog rather than cluttering the active board. The backlog is where raw ideas wait until they're refined enough to schedule.
2. Size the work with story points. Cards carry story points, so the team can talk about relative effort instead of arguing about hours. If your team is new to relative sizing, our practical guide to story points covers how to run it without the usual velocity theater.
3. Plan the sprint. Pull refined cards from the backlog into a sprint. Because points are on the cards, capacity math is straightforward: compare the sprint's total against what the team finished last time.
4. Work the scrum board. During the sprint, the scrum board shows the active sprint's cards moving across columns. Checklists on cards break stories into concrete steps; custom fields let you track whatever your team cares about — environment, severity, customer, component.
5. Review sprint insights. When the sprint ends, sprint insights show you how the sprint actually went, which feeds directly into the retro (more on that below).

A few features worth building habits around:

• Card templates. If every bug report should include reproduction steps and every story should include acceptance criteria, encode that once as a card template. New cards start from structure instead of a blank text box.
• Tree view. For epics that break into stories that break into tasks, tree view shows the hierarchy directly, which is far easier to groom than a flat list.
• Timeline view. When someone asks "when does this land?", switch to timeline view instead of guessing.
• User-flow diagrams. The Kanban room can hold user-flow diagrams alongside the work, so the flow you're building lives next to the tickets that build it.
• Per-board AI chat. Every board has its own AI chat with the board as context. Ask it what's left in the sprint, ask it to draft cards from a feature description, ask it to summarize what shipped. It's scoped to the board, so answers are grounded in your actual work.

If you're not sure whether you want sprints at all, the board works fine as pure Kanban — continuous flow, no sprint container. You can adopt sprints later without migrating anything. The board also ships with 36 templates, so a new squad can start from a proven structure rather than a blank board.

Replace the daily meeting with async check-ins

The daily standup meeting is the most commonly held and most commonly resented ritual in software. Fifteen minutes on the calendar becomes twenty-five in practice, and for a distributed team it lands at 7 a.m. for someone.

The Check-in room replaces it with a written async version. Here's the setup:

1. Pick a template. The room ships a 36-template library across industries. For a software team, a daily standup template with the classic prompts — what you did, what you're doing, what's blocking you — is the natural start. Edit the questions to fit; the best standup prompt is the one your team actually answers honestly.
2. Schedule it. Check-ins run on a schedule. A daily check-in posts its prompts on your cadence, and each person answers when they start their day — whatever time zone that day starts in.
3. Turn on mood tracking. Each response carries a green/yellow/red mood. One glance at the roster tells you more than fifteen minutes of "yeah, fine, no blockers" ever did.
4. Use status flags. Responses can carry flags like Blocked, Help, Milestone, and Kudos. A flag turns a paragraph of prose into a signal a lead can scan for. Blocked flags are the ones to sweep every morning — a blocker flagged at 9 a.m. and cleared by 10 is the async standup doing its job.
5. Read Team Pulse. The room's Team Pulse analytics aggregate mood and participation over time. A slow slide from green to yellow across three weeks is exactly the kind of trend a daily meeting hides and a chart reveals.
6. Publish digests. Check-ins can be published as digests, so a week of standups can roll up into something a stakeholder or an adjacent team can read without joining the room's daily rhythm.

Two norms make this work. First, answers should be written for readers, not for compliance — "worked on the API" helps nobody; "finished pagination on /orders, starting on rate limiting, blocked on staging access" helps everyone. Second, a flag must trigger a response. If Blocked flags go unanswered for a day, people stop raising them. We've written a deeper piece on the format itself — why async standups beat daily meetings for most teams — including when the synchronous version still wins.

Make retrospectives worth attending

Retros fail in predictable ways: same format every time, loudest voice wins, action items evaporate. The Retrospective room is built against all three.

Vary the format. The room ships 12 formats — Mad-Sad-Glad, 4Ls, Start-Stop-Continue, and nine more. Rotating formats keeps the team from giving the same three answers on autopilot. A format change is the cheapest way to get new information out of the same people.

Collect honestly, then discuss. The board is real-time and multiplayer, so the team adds cards simultaneously during the collection phase. Cards come in 7 flavors — plain text, but also GIFs, polls, health checks, and drawings — which sounds like a gimmick until you watch a poll card settle a "was this sprint actually worse than usual?" debate with data instead of vibes.

Group and vote. Once cards are in, drag related ones into groups, then vote. Voting forces prioritization: the retro discusses the top-voted themes, not whatever card happens to sit top-left. Presentation mode keeps the room focused on one thing at a time while you walk the results.

Capture actions and actually export them. The retro's output is its action list. The room supports CSV export of actions, and the workflow we recommend is blunt: export the actions and put them on your Kanban board as cards, in the sprint, with owners. An action item that doesn't reach the board didn't happen. Open the next retro by reviewing the last retro's actions — the fastest way to teach a team that retros matter is to show that their output gets done.

Let the AI write the summary. The room generates an AI meeting summary, so the write-up that nobody volunteers for takes zero minutes. Post it where the team will see it — the feed, or the wiki if you keep a retro archive.

For facilitation technique, format selection, and how to handle the retro where everything is on fire, see the complete guide to retrospectives.

Build your internal Stack Overflow with Q&A

Every engineering team answers the same questions repeatedly. How do I set up the dev environment on a new laptop? Why does the deploy script need that flag? What's the accepted pattern for feature flags in this codebase? The answers live in Slack scrollback, which is to say they're gone.

The Q&A room is a private Stack Overflow for exactly this:

• Questions are Markdown, so code blocks, stack traces, and config snippets render properly instead of arriving as mangled plain text.
• Tags organize by area — deploys, local-setup, payments, postgres — and filters let you browse or search within a tag.
• Up/downvotes surface the best answer among several, and the question author (or a moderator) marks one as accepted. Accepted answers matter enormously: they turn a discussion into a reference. A question with an accepted answer is a documented decision; a Slack thread is an archaeology project.
• Related questions appear alongside each question, which catches duplicates before they're posted and helps a searcher who phrased the problem differently.
• The analytics dashboard shows what's being asked. This is underrated: your Q&A analytics are a map of your documentation gaps. If four people asked about staging credentials this month, that's not a Q&A problem, that's a missing runbook.

Seeding matters. A Q&A room with zero questions stays at zero. Spend one hour in the first week posting the ten questions your team already answers in DMs — and answering them. Ask new hires to post every question they hit during onboarding; they're the only people who can still see the gaps.

Give specs and runbooks a real home

Openbook has two knowledge rooms, and software teams generally want both — for different jobs.

Docs is a Notion-style block editor: slash menu, tables, rich blocks, and an infinitely nested page tree with inline search. Use it for the documents that are worked on — specs, RFCs, design docs, project one-pagers. The nested tree means a project's spec can hold its sub-pages (API design, rollout plan, open questions) underneath it.

Wiki is a Markdown knowledge base with a side-by-side live GitHub-flavored preview. Use it for the documents that are referenced — runbooks, onboarding guides, architecture notes, coding standards. Engineers already write Markdown all day; the wiki meets them where they are, and GFM preview means tables, code fences, and task lists render exactly like they do in a pull request description.

A simple division that holds up well: if the document has an end state, it's a Doc. If it should be true forever and edited whenever reality changes, it's a Wiki page. And when a Q&A answer keeps getting linked, promote it to a wiki page — that's the capture loop working.

Plan releases on the Gantt

Sprints handle the next two weeks. Releases need dates, and dates need dependencies. The Gantt room covers the part of software planning that boards are bad at:

• Drag-to-schedule bars on a timeline with day/week/month zoom.
• Milestones for the dates that don't move — the conference demo, the contract deadline, the marketing launch.
• Drawn dependencies between bars, and a critical path view that shows which chain of work actually determines the ship date. When someone asks whether a delay matters, the critical path answers it: off the path, you have float; on it, the release just moved.
• Import from boards, so the Gantt is built from the real work items on your Kanban board rather than a parallel universe of hand-typed bars.
• An AI plan generator for first drafts — describe the release and get a starting timeline to correct, which is faster than starting from nothing. It ships with 14 templates as well.

The workflow: plan the release once on the Gantt, run the sprints on the board, and revisit the Gantt at sprint boundaries to reconcile plan with reality. That's a ten-minute check, not a planning ceremony.

Report status without status meetings

Stakeholders deserve answers; your sprint doesn't deserve interruptions. Two rooms handle this without a single recurring meeting.

The Project Status room is structured async reporting: standing questions the lead answers on a cadence (what shipped, what's next, what's at risk), a goals board with RAG status for the quarter's commitments, and narrative updates with a history timeline, so anyone can read the current state and scroll back through how it evolved. Honest RAG discipline matters more than the tool — a goal that goes red the moment it's at risk is useful; one that goes red the week it fails is theater.

The Dashboard room is a drag-and-resize canvas of widgets — stat tiles, progress bars, bar and donut charts, and recent-cards tables — wired live to your boards. Build one view with sprint progress, bug counts by status, and the most recent cards, and the "how's it going?" question answers itself. Give stakeholders Viewer access via roles and permissions and they can watch without touching.

The connective tissue: chat, search, and the AI assistant

Three platform features tie the whole space together.

Chat is a Slack-style messenger — channels, DMs, presence, typing indicators, unread badges — plus a floating chat widget available on every page, so quick questions don't require leaving the board. The practical norm for software teams: chat is for coordination that expires ("deploying now, hold merges"), and anything with a shelf life goes to Q&A, the wiki, or the board. Chat is where information goes to be seen; rooms are where it goes to be found.

Global ⌘K search (command search) reaches across every room in the space — cards, docs, questions, messages. One shortcut, one index, no "which tool was that in?"

The AI assistant is global and takes real actions — around 25 tools' worth: creating tasks, posting updates, inviting members, and more, with confirmation required for destructive actions. It's bring-your-own-key, supporting Anthropic, OpenAI, and DeepSeek, so you choose the model and hold the key. For a software team the everyday wins are mundane and constant: "create cards for these five bugs from this pasted email," "summarize this week's check-ins," "draft a status update from the board." See the full assistant guide for setup and the complete tool list.

A sprint cycle, end to end

Here's what a two-week cycle looks like with the space assembled:

Day	Ritual	Room
Day 1, morning	Sprint planning: pull sized cards from backlog into the sprint	Kanban Board
Every workday	Async standup with mood + flags; lead sweeps Blocked flags	Check-in
Ongoing	Questions asked and answered; good answers accepted	Q&A
Day 5	Mid-sprint: check timeline view, reconcile the release Gantt	Kanban, Gantt
Day 9	Post the sprint's status update; refresh RAG on goals	Project Status
Day 10, morning	Review sprint insights	Kanban Board
Day 10, afternoon	Retro: new format, vote, export actions to the board	Retrospective
Continuous	Dashboard stays live; stakeholders self-serve	Dashboard

Total recurring meeting time: the planning session and the retro. Everything else is async, written, and searchable.

Next steps

You can have this running today:

1. Create a space from the Software template — it provisions and seeds the core rooms in one click.
2. Invite the team. Openbook's Free plan is $0 with unlimited rooms and members and all 18 room types, so the whole squad gets in without a procurement conversation.
3. Run one full sprint in the space before judging it — plan on the board, stand up in the Check-in room, retro at the end. One complete cycle tells you more than any feature list.
4. Add rooms as needs appear — Q&A when the same question gets asked twice, the Gantt when a real deadline shows up, the Dashboard when a stakeholder asks for numbers.

When you want unlimited history, dashboards, and the AI assistant, Pro is $15 per user per month ($12 annual) with a 14-day free Pro trial — details on the pricing page. For the broader picture of what Openbook replaces and how the pieces fit, start with the product overview.

One team, one space, one tool doing the work of five. Ship something with it.