What is a release?
A release is a named batch of work that ships together, like version 1.4.0 of an app. It has a name, a target date and a list of tasks. When the tasks are done, you ship it.
For an app, the release is what reaches people's phones. For a website, it might be a launch. This post shows how a release differs from a sprint and an epic, and how big one should be. It is one of the plain explainers on our blog.
An example
Luka, Mira and Ivan are planning version 1.4.0 of a client's shopping app. They give it one line: "New checkout, and the two crash fixes." They set a target date at the end of the month.
Then they add tasks to it. Five come from the new checkout work. Two are bug fixes. That is the whole release. A request for dark mode comes in the next week. It goes to 1.5.0, not 1.4.0.
Two days before the date, one task is not ready. They move it to 1.5.0 and ship the rest. Then they mark 1.4.0 as shipped. How a three-person team ships a release walks through each step.
Release vs sprint vs epic
These three words get mixed up, because all three group tasks. They group them in different ways.
| What it groups | What ends it | Example | |
|---|---|---|---|
| Release | Work that ships together | Shipping | 1.4.0 |
| Sprint | Work for a fixed block of time | The calendar | Sprint 14, two weeks |
| Epic | Work toward one goal | Reaching the goal | New checkout page |
A sprint is a fixed block of time, often two weeks, with a set list of work. An epic is a big piece of work split into smaller tasks. What an epic is goes into more detail.
A release cuts across both. Tasks from one epic can ship in two releases. One release can hold tasks from three epics.
How big it should be
For a small team, a release should be a few weeks of work at most. Small releases are easier to test. When something breaks, there are fewer places to look.
A good test is one sentence. Can you say what the release is for? "New checkout and two crash fixes" passes. "Lots of stuff" does not.
If a release keeps slipping, it is too big. Make it smaller, ship the part that is ready, and move the rest to the next one.
Common mistakes
- No date. Without a target, a release grows until someone panics.
- Adding work after you fixed the scope. The scope is the list of what is in. Each small extra pushes the date.
- Treating a release like an epic. An epic is a goal. A release is a list with a shipping date.
- Not writing down what shipped. In six months, someone will ask what changed in 1.4.0.
How devBoard handles it
A release in devBoard has a name and a target date. You add tasks to it, and when it goes out you mark it shipped. A saved view can filter by release, so you see what is left for 1.4.0 in one list. There are no sprints. Small teams use releases instead, so the plan follows what ships, not the calendar. devBoard does not write release notes for you. Releases in devBoard shows the screens, and the guide to planning a release takes you through your first one.
Questions people ask
What do the numbers in 1.4.0 mean?
Many apps use three numbers. The first goes up for a big change, the second for new features, and the third for fixes. So 1.4.1 would be a fix to 1.4.0.
Is a release the same as a sprint?
No. A sprint ends on a set date, done or not. A release ends when it ships. Many small teams skip sprints and plan by release.
Can a task be in two releases?
No. A task ships once. If it misses a release, move it to the next one.
Free while in early access; paid plans will be one plain number, posted here first.
Download on the App Store Get it on Google Play Connect your AI assistant