# \[Feature Request\] Visibility and Drag-and-Drop Support for Standalone Tasks in the Backlog **URL:** \ **Category:** Feature requests\ **Tags:** scrum\ **Created:** [September 6, 2026, 9:22pm UTC](https://community.taiga.io/t/feature-request-visibility-and-drag-and-drop-support-for-standalone-tasks-in-the-backlog/8943 "2026-09-06T21:22:47Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![DudjackOneArmed](https://dub1.discourse-cdn.com/flex017/user_avatar/community.taiga.io/dudjackonearmed/32/6130_2.png) [@DudjackOneArmed](https://community.taiga.io/u/DudjackOneArmed)\ **Post date:** [September 6, 2026, 9:22pm UTC](https://community.taiga.io/t/feature-request-visibility-and-drag-and-drop-support-for-standalone-tasks-in-the-backlog/8943/1 "2026-09-06T21:22:47Z")
I’d like to propose adding visibility and drag-and-drop support for standalone tasks (tasks not attached to a user story) within the Backlog view. ## **Use case** Currently, the Taiga backlog exclusively displays User Stories. Standalone tasks are completely absent from this view; they can only be created or managed directly on the Sprint board. This creates a significant planning gap. Teams often have independent work items (such as technical debt, minor bug fixes, deployments, or operational tasks) that do not logically belong to any specific user story. Because these tasks are invisible in the backlog, they cannot be prioritized, refined, or pulled into an upcoming sprint during standard backlog planning sessions. If a team needs to plan such work, they are forced to either create unnecessary “dummy” user stories just to make the task visible, or manage these tasks outside of the normal planning flow. ## **Desired behavior** It would be highly beneficial to introduce a dedicated tab, section, or filter in the Backlog view specifically for “Standalone Tasks” (or “Unlinked Tasks”). Furthermore, these tasks should be draggable from this backlog view directly into a specific sprint, mirroring the current behavior of User Stories. This would allow teams to: - Plan and prioritize all types of work holistically during sprint planning, not just story-bound work. - Easily move independent tasks between sprints or from the general backlog without losing context, comments, or history. - Keep the backlog clean and meaningful, avoiding the creation of artificial “dummy” user stories. This feature would significantly improve workflow flexibility and backlog management for teams that need to track independent operational tasks alongside standard user stories. ---
**Author:** ![Charlie](https://avatars.discourse-cdn.com/v4/letter/c/d6d6ee/32.png) [@Charlie](https://community.taiga.io/u/Charlie)\ **Post date:** [September 8, 2026, 11:34am UTC](https://community.taiga.io/t/feature-request-visibility-and-drag-and-drop-support-for-standalone-tasks-in-the-backlog/8943/2 "2026-09-08T11:34:38Z")
Hi there! This is kind of already present in the sprint taskboard; there is a section at the bottom called storyless tasks. Is that more or less what you envision? Best! ---
**Author:** ![DudjackOneArmed](https://dub1.discourse-cdn.com/flex017/user_avatar/community.taiga.io/dudjackonearmed/32/6130_2.png) [@DudjackOneArmed](https://community.taiga.io/u/DudjackOneArmed)\ **Post date:** [September 8, 2026, 2:48pm UTC](https://community.taiga.io/t/feature-request-visibility-and-drag-and-drop-support-for-standalone-tasks-in-the-backlog/8943/3 "2026-09-08T14:48:22Z")
Hi there, Thanks! However, that is not quite what I envision. The “storyless tasks” section at the bottom of the sprint taskboard is only visible and usable _after_ a sprint has already started. The core issue is the lack of a **backlog view for standalone tasks** _prior_ to sprint planning. Currently, the Backlog exclusively displays User Stories. During sprint planning, we can only drag and drop User Stories into the upcoming sprint. Because there is no backlog of regular tasks, if we want to include a standalone task in a future sprint, we are forced to create “fake” (or “dummy”) User Stories just to make the task visible and movable during the planning phase. What I am proposing is a dedicated backlog section (or tab) for standalone tasks, allowing us to: 1. See and prioritize these tasks alongside User Stories _before_ the sprint starts. 2. Drag and drop them directly into a future sprint during the planning session, without needing artificial User Stories as a workaround. Does this clarify the use case? Best regards ---
**Author:** ![Charlie](https://avatars.discourse-cdn.com/v4/letter/c/d6d6ee/32.png) [@Charlie](https://community.taiga.io/u/Charlie)\ **Post date:** [September 9, 2026, 8:19am UTC](https://community.taiga.io/t/feature-request-visibility-and-drag-and-drop-support-for-standalone-tasks-in-the-backlog/8943/4 "2026-09-09T08:19:35Z")
Thanks for the suggestion and for explaining the use case. I think the main point here is that, in Taiga, user stories are the main work items, both in Scrum and Kanban. Despite the name, a user story doesn’t necessarily have to be written as a traditional “As a user, I want…” story, or even represent user-facing functionality. It can also be technical debt, maintenance work, a deployment, an infrastructure change, etc. Tasks have a different role. They are intended to be a more detailed breakdown of the work needed to complete a user story. In Scrum, Taiga also allows standalone tasks inside a sprint for those cases where a task doesn’t really belong to a particular user story. If we made standalone tasks first-class items in the backlog as well, we would end up with user stories and tasks serving essentially the same purpose there, and I’m not sure that would make the model clearer. So for work that needs to be prioritized and managed as a main item, we would normally expect it to be a user story, whether you are using Scrum or Kanban. Tasks are there when you want to break that work down further. That said, I can see how the name “user story” can make this less obvious, especially when the work is purely technical or operational. ---
**Author:** ![DudjackOneArmed](https://dub1.discourse-cdn.com/flex017/user_avatar/community.taiga.io/dudjackonearmed/32/6130_2.png) [@DudjackOneArmed](https://community.taiga.io/u/DudjackOneArmed)\ **Post date:** [September 9, 2026, 6:39pm UTC](https://community.taiga.io/t/feature-request-visibility-and-drag-and-drop-support-for-standalone-tasks-in-the-backlog/8943/5 "2026-09-09T18:39:41Z")
Hello! Thank you for the detailed explanation. Yeap, I understand Taiga’s philosophy, where “User Stories” serve as the primary work items and can represent technical debt or operational tasks (not just features visible to the end user). However, in practice, many teams prefer their product backlog to focus on product value (features, epics), while keeping operational, service-related, or minor technical tasks separate. When we have to create a “User Story” for a simple operational task (such as “update server certificate” or “fix CI pipeline”), two practical issues arise: 1. **Backlog clutter:** mixing high-level product features with minor technical tasks makes it difficult for Product Owners to prioritize based on actual product value. 2. **Process overhead:** a User Story often implies specific documentation, acceptance criteria, and workflow stages (all of which are unnecessary for an operational task that takes just an hour). Consequently, we end up having to create an custom field (e.g., “sub-type”) to explain why that user story lacks these attributes. You rightly noted that the term “User Story” can be misleading when applied to technical tasks. It is precisely because of this terminological mismatch that teams prefer using “Tasks” or “Issues” for such work; however, they then face difficulties managing them or moving them to future sprints if they aren’t linked to stories. Our team has encountered this exact situation. Since Taiga already supports “storyless tasks” _within_ an active sprint, the current functional gap exists solely at the **planning stage**. The goal is not to change the basic Scrum model, but to spare teams from having to create artificial user stories solely for the sake of effective work planning. Thank you for taking the time and for continuing to improve Taiga. Best regards