# Kanso guides: PRDs, kanban, releases and team practice

> Guides for software teams.

Short, practical guides for software teams, from the first spec to the release.

Web page: https://kansohq.app/guides

## Specs and requirements

Write down what to build, and how you will know it is done.

- [What is a PRD? How to write one, step by step](https://kansohq.app/guides/what-is-a-prd.md): A PRD is a product requirements document. Learn what goes in one, how long it should be, how to write it step by step and the mistakes to avoid.
- [How to write a product spec your team will read](https://kansohq.app/guides/how-to-write-a-product-spec.md): A good product spec is short, specific and honest about what is not decided. Learn how to write one, what to leave out and how to keep it current.
- [How to write acceptance criteria, with examples](https://kansohq.app/guides/how-to-write-acceptance-criteria.md): Acceptance criteria say when a task is done. Learn how to write them as clear true-or-false lines, with examples and a checklist for software teams.
- [How to write a technical design doc](https://kansohq.app/guides/how-to-write-a-technical-design-doc.md): A technical design doc explains how you will build something and why. Learn the sections to include, how to compare options and how to get a useful review.
- [What is an architecture decision record (ADR)?](https://kansohq.app/guides/what-is-an-adr.md): An architecture decision record (ADR) is a short note on a decision, why it was made and what follows. Learn the format, when to write one and examples.

## Boards and tasks

Keep the work visible, in order and owned by someone.

- [What is a kanban board? A guide for software teams](https://kansohq.app/guides/what-is-a-kanban-board.md): A kanban board shows work as cards moving through columns. Learn how it works, how it differs from scrum and how software teams use it well.
- [How to set up a kanban board for a software team](https://kansohq.app/guides/how-to-set-up-a-kanban-board.md): Set up a kanban board in eight steps: map your process, choose columns, size cards, set limits and review weekly. Includes column sets for software teams.
- [How to run a bug tracking board that stays tidy](https://kansohq.app/guides/bug-tracking-board.md): Run a bug tracking board that does not turn into a graveyard: what a bug card needs, how to triage, how to rank bugs and when to close them.
- [The MoSCoW method: Must, Should, Could explained](https://kansohq.app/guides/moscow-prioritization.md): The MoSCoW method sorts work into Must, Should, Could and Won’t. Learn what each means, how much to put in Must and how software teams use it.
- [Definition of done vs acceptance criteria](https://kansohq.app/guides/definition-of-done.md): A definition of done is a team-wide checklist every task must meet. Learn how it differs from acceptance criteria, with an example list to adapt.

## Releases and launches

Get what is ready out of the door without surprises.

- [How to plan a software release, step by step](https://kansohq.app/guides/how-to-plan-a-software-release.md): Plan a software release in seven steps: fix the date, freeze the scope, split the work by team, track blockers and decide go or no-go. With a checklist.
- [A software launch checklist, step by step](https://kansohq.app/guides/software-launch-checklist.md): A software launch checklist for product, quality and go-to-market, plus launch day and what to do after. Copy it, give every line an owner and ship.
- [How to write release notes people read](https://kansohq.app/guides/how-to-write-release-notes.md): Good release notes say what changed and why it matters, in plain words. Learn the structure, a before-and-after example and what to leave out.

## Team practice

Planning, retrospectives, postmortems and notes that people actually use.

- [How to run a retrospective that changes something](https://kansohq.app/guides/how-to-run-a-retrospective.md): A retrospective is only worth it if something changes afterwards. Learn a simple format, how to run it in an hour and how to follow through.
- [How to write a blameless incident postmortem](https://kansohq.app/guides/how-to-write-a-postmortem.md): A blameless postmortem explains what broke, why and what changes. Learn the sections, how to write the timeline and root cause, and an example.
- [How to plan a sprint without overcommitting](https://kansohq.app/guides/how-to-plan-a-sprint.md): Sprint planning in five steps: set a goal, check capacity, choose work, break it down and name the risks. Includes how teams without sprints do it.
- [How to take meeting notes your team will use](https://kansohq.app/guides/how-to-take-meeting-notes.md): Good meeting notes record decisions and actions, not a transcript. Learn a simple structure, who takes notes and how to make sure actions happen.

## Choosing tools and growing a team

From a handful of people to many teams building one product.

- [Project management for software teams, explained](https://kansohq.app/guides/project-management-for-software-teams.md): Project management for software teams in plain words: what to manage, a light system that works at any size, the rhythm to keep and the mistakes to avoid.
- [Choosing project management software for a dev team](https://kansohq.app/guides/choosing-project-management-software.md): How to choose project management software for a software team: the questions to ask, the kinds of tool on offer and how to test one on real work.
- [Project management for large software teams](https://kansohq.app/guides/project-management-for-large-software-teams.md): How to manage software work across many people and teams: clear ownership, one view of cross-team launches, roles, written decisions and the right tools.
- [Project management for growing software teams](https://kansohq.app/guides/project-management-for-growing-teams.md): What breaks as a software team grows from 5 to 50 people, and the small changes that fix it: owners, written decisions, shared dates and a steady rhythm.
- [How remote software teams stay in sync](https://kansohq.app/guides/remote-software-teams.md): How remote and distributed software teams stay in sync: write things down, make status visible, use chat well and keep meetings for decisions.
- [Why team chat should link to the work](https://kansohq.app/guides/team-chat-linked-to-tasks.md): Chat and task tools drift apart. See why team chat should link to tasks, how to keep decisions from getting lost in threads and habits that help.
- [How to plan your week around your tasks](https://kansohq.app/guides/how-to-plan-your-week.md): A weekly planning habit for engineers and team leads: gather due dates, estimate honestly, rank what matters and leave room for the unexpected.
- [A checklist for onboarding a new engineer](https://kansohq.app/guides/onboarding-a-new-engineer.md): A checklist for onboarding a new software engineer: before day one, the first day, the first week and the first month, with a small first task.

[Kanso home, with plans and prices](https://kansohq.app/index.md)