Release planning for software teams that skip Scrum
Most teams ship software without Scrum. They don't run sprints, they don't estimate story points and they don't calculate velocity. But they still need to know what's going into the next release and whether the timeline is realistic.
The problem is that most project management tools assume you're doing some flavor of agile ceremonies. Release planning features are buried inside sprint configurations. If you skip sprints, you lose the planning tools too.
Release planning without Scrum sprints is the practice of organizing work into named releases (like v2.0 or Q3 Launch), assigning tasks to those releases using labels and using a timeline view to visualize when each release's work lands over time. No velocity calculations, no sprint commitments, no story points required.
TL;DR: Create a label for each release milestone. Assign issues to releases by labeling them. Use a timeline view grouped by label to see all releases laid out over time. Spot scheduling conflicts visually, adjust dates by dragging and keep your board for daily execution.
Why release planning without Scrum sprints still matters
Skipping Scrum doesn't mean skipping planning. You still need to answer basic questions:
- What's shipping in the next release?
- Are we on track to hit the target date?
- Is any single week overloaded with work?
- Which features are at risk of slipping?
Without a structure for answering these, release planning happens in people's heads. Someone "knows" the release is on track because they talked to a few people. Then a feature slips and nobody saw it coming.
You don't need sprints to answer these questions. You need a way to group work by release and see it on a timeline.
How release planning without Scrum sprints works in Eigenfocus
Here's the practical setup. It takes about five minutes and works for any team that ships in named releases, versioned milestones or time-based batches.
Step 1: Create a label for each release
Go to your project settings and create labels for your upcoming releases. For example:
- v2.0 (blue)
- v2.1 (green)
- v2.2 (orange)
Labels in Eigenfocus are colored, so each release gets a distinct visual identity on your board and timeline. You can also use date-based names like "March Release" or "Q2 Launch" if that fits your team better.
Step 2: Assign issues to releases
Label each issue with its target release. A feature called "User dashboard redesign" gets the v2.0 label. A bug fix for "CSV export timeout" gets v2.1. This is your release assignment step, no sprint planning meeting needed.
Every issue also needs a start date and due date to show up on the timeline. Set these based on when you expect the work to begin and end.
Step 3: Create a timeline view grouped by label
Create a new view in your project. Choose Timeline as the type and set the grouping to Label. Now you see your releases as horizontal swimlanes, with each issue displayed as a bar spanning its start-to-due-date range.
Each label group shows all the issues assigned to that release, laid out over time. You can immediately see which weeks are packed, which releases overlap and whether any issue stretches longer than expected.
Step 4: Use the board for daily work
Your board view stays your daily driver. Developers pick issues from the board based on status columns. The timeline is for weekly planning check-ins where you review the release schedule and adjust dates if needed.
This two-view approach, timeline for planning and board for execution, is covered in more detail in the guide on planning deliverables with a timeline view.
What does release planning look like for a v2.0 release?
Let's walk through a concrete example. Your team is building a project management app and the v2.0 release is targeting July 18. Here are the features:
| Issue | Assignee | Start | Due | Label |
|---|---|---|---|---|
| User dashboard redesign | Sarah | Jun 16 | Jul 2 | v2.0 |
| Notification preferences | Marco | Jun 16 | Jun 27 | v2.0 |
| API rate limiting | Sarah | Jun 23 | Jul 9 | v2.0 |
| Bulk export improvements | Priya | Jun 30 | Jul 11 | v2.0 |
| Onboarding flow v2 | Marco | Jun 30 | Jul 16 | v2.0 |
| Release QA and bug fixes | Priya | Jul 14 | Jul 18 | v2.0 |
You also have three issues labeled v2.1 starting in mid-July.
What the timeline grouped by label shows you:
The v2.0 swimlane has six bars spread across five weeks. Right away you can see:
Sarah has overlapping work. "User dashboard redesign" runs Jun 16 - Jul 2 and "API rate limiting" starts Jun 23. She has a week of overlap. Is that realistic? If the dashboard redesign is wrapping up by then, maybe. If not, push "API rate limiting" start to Jun 30.
The week of Jun 30 is heavy. Three issues are active that week (API rate limiting, Bulk export and Onboarding flow). If your team is three people, that's everyone at full capacity with no buffer.
QA has four days. "Release QA and bug fixes" runs Jul 14-18. That's tight. If "Onboarding flow v2" slips by even two days, QA gets squeezed. You might want to start QA on Jul 11 instead.
v2.1 work starts before v2.0 ships. Some v2.1 issues begin mid-July while v2.0 is still in QA. That's fine if different people are working on them. If not, you have a resource conflict.
You spotted four potential problems in about 30 seconds of looking at the timeline. On a board, these issues are invisible because boards don't show time.
Switch the grouping to assignee and you see each person's load. Sarah has two overlapping bars. Marco has a gap in late June. Priya is clear until Jun 30 then stacked through the release.
How does this compare to sprint-based release planning?
In Scrum, releases are a function of sprints. You plan two-week sprints, commit to a set of stories and after several sprints, you bundle the completed work into a release. Release dates are derived from velocity: if you complete 20 points per sprint and the release has 80 points remaining, that's four sprints out.
This works well when:
- Your team has stable velocity over multiple sprints
- Work items are consistently sized
- You have a dedicated Scrum Master running the process
It breaks down when:
- Your team's output varies week to week
- You don't estimate in story points (or don't want to)
- You just want to see what's planned and whether the dates work
Label-based release planning skips the abstraction layer. Instead of deriving dates from velocity, you set dates directly. Instead of grouping work into sprints, you group it into releases. The timeline shows you the reality of your schedule without converting anything into points first.
Neither approach is better in absolute terms. But if you're not running Scrum, forcing sprint mechanics just for release planning adds overhead without value.
What happens when a release slips?
Releases slip. A feature takes longer than expected, a critical bug shows up or a dependency gets delayed. Here's how to handle it with this setup.
- Update the issue dates. Drag the bar on the timeline or edit the dates directly. The timeline reflects the change immediately.
- Check for cascading effects. Does the slipped feature push other work? Look at the timeline for new overlaps.
- Decide whether to cut scope. If the release date is fixed, move lower-priority issues to the next release by changing their label from v2.0 to v2.1.
- Communicate the change. The timeline is your source of truth. Anyone on the team can open it and see the current state.
This is where labels shine. Moving an issue from one release to another is just changing a label. No sprint re-planning, no backlog grooming session.
When should you review your release timeline?
A weekly check is enough for most teams. Pick a day, open the timeline grouped by label and spend 10 minutes reviewing:
- Are any issues past their due date?
- Did new issues get added to the current release?
- Is any week overloaded?
- Does the release date still look realistic?
Some teams do this in a Monday planning meeting. Others have the project lead review it async and post a summary. Either way, the timeline gives you the visual context to make decisions quickly.
For teams managing work across different views, the guide on when to use each project view explains how boards, lists, timelines and grids complement each other.
Can you combine labels for releases with labels for other things?
Yes. Labels in Eigenfocus are flexible. You might have release labels (v2.0, v2.1) alongside category labels (Frontend, Backend, Design). An issue can have multiple labels.
When you group the timeline by label, each label gets its own swimlane. So an issue labeled both "v2.0" and "Frontend" will appear in both groups. This is useful if you want to switch between a release-focused view and a category-focused view without changing your data.
If you want a workflow that separates bug triage from release planning, you can run both in the same project. See the guide on building a bug triage workflow for a compatible setup.
How do you keep release planning simple?
Keep release labels to 2-3 at a time. Don't create labels for releases six months out. Plan the current release and the next one. Add new labels as you get closer.
Set start dates, not just due dates. A due date tells you when something needs to be done. A start date tells you when someone should begin working on it. Both are required for the timeline to be useful.
Don't label everything. Some issues are operational or maintenance work that doesn't belong to a release. That's fine. Unlabeled issues still appear on your board and in your list. They just won't show up in the release timeline.
Use the board for daily standup context. Your board grouped by status shows what's in progress, what's blocked and what's done. The timeline shows the plan. Don't try to make one view do both jobs.
Frequently asked questions about release planning without Scrum sprints
Do I need story points to plan a release?
No. Story points are a Scrum estimation tool. With label-based release planning, you set start and due dates for each issue directly. The timeline shows you whether the schedule is realistic based on how work overlaps over time, not based on a points calculation.
How do I track release progress without velocity?
Open your timeline grouped by label and look at your release swimlane. Completed issues (those in a "Done" status) are visible alongside in-progress and upcoming work. You can see how much of the release is done, what's active and what hasn't started. Progress is visual, not a number.
Can I use this approach for continuous deployment?
Yes. Even teams that deploy continuously often batch features into named releases for communication purposes. "Version 3.1 includes these five features" is easier to communicate to users than individual deploy timestamps. The labels and timeline give you that grouping without imposing a batch deployment process on your engineering workflow.
What if my team is already using Scrum and wants to stop?
Start by dropping sprint boundaries and switching to release labels. Keep your existing board and statuses. Add a timeline view grouped by label. You'll have release visibility without sprint ceremonies within the same day. The transition is incremental, not all-or-nothing.
How many issues should a single release contain?
There's no fixed number. A release with 5 issues and one with 25 issues can both work. What matters is whether the timeline shows a realistic schedule. If you look at the timeline and one release is packed into two weeks with 20 overlapping bars, that's too much. If the work is spread across reasonable timeframes with manageable overlap, the count doesn't matter.
Start planning releases with a timeline view
Create your release labels, assign issues and open a timeline view grouped by label. The whole setup takes five minutes. No sprints, no velocity and no story points.
See how teams use Eigenfocus for software development, explore all features or read about simple work estimation without story points.