PlanMagnet
Work & Sprints3 illustrations

Task Board and AI Work Breakdown

The board where work moves, the form that adds to it, and an assisted breakdown that turns a paragraph of intent into reviewable work items.

These images are illustrations of the concept, not screenshots of the actual product.

Overview

This concept covers the daily surface of PlanMagnet: the task board a team works from, the form that puts an item on it, and an assisted breakdown that takes a written request and proposes the work items behind it. The three illustrated screens run from the board, through manual creation, to a faster path that still ends in a human decision.

The problem it addresses is the gap between a request and a backlog. Someone writes a paragraph describing what a customer needs, and turning that into an epic with tasks, stories and the occasional bug is slow, inconsistent work that usually happens in one person's head. Estimates get invented on the spot, work types are applied unevenly, and by the time the items exist the original wording has been lost. Meanwhile the board that everything lands on has to stay simple enough to use every morning.

In the illustrated experience the board sits under a tasks section that expands into just two entries — the board itself and a create action — keeping the daily path short. The create-task form is a single card: a title, a description, then a compact grid of project, priority and work type, followed by story points, a sprint identifier and a due date, and a comma-separated label field. Nothing is buried behind tabs, and the defaults shown mean a small task can be filed without touching most of the fields.

The breakdown view is the most opinionated screen of the three. It is split in two: on the left, a text area where a feature request is pasted, with a character counter and a provider selector for the model that will read it; on the right, a table of suggested work items with columns for title, work type, priority and an hour estimate. Each row carries a checkbox and an edit control, an assisted badge counts the suggestions, and a caution line states that nothing is saved until the user confirms. The confirm button names exactly how many items the current selection would create, so the human decision stays explicit.

In the wider product these items are what sprint planning draws from, what the at-risk sweep inspects, and what the delivery analytics counts. The run details printed under the suggestions — an identifier, the model, elapsed time and token counts — connect this surface to the record of assisted activity kept elsewhere in the product.

What this concept shows

  • A tasks section that expands to just a board and a create action, keeping the everyday path short
  • A single-card create-task form covering title, description, project, priority, work type, story points, sprint and due date
  • A comma-separated label field with example labels shown as placeholder text
  • A split breakdown view pairing a pasted request with the work items proposed from it
  • A character counter and a provider selector for the model that reads the request
  • A suggestions table with work type and priority badges, hour estimates, per-row editing and per-row selection
  • A caution that suggestions are not saved until confirmed, with a confirm button that names the exact count selected
  • Run details under the suggestions showing an identifier, the model, elapsed time and token usage

How it works

  1. Open the tasks section from the module rail and land on the task board, with a create action one step away.
  2. Add work directly with the create-task form, filling in a title and description.
  3. Set the project, priority and work type, then add story points, a sprint and a due date, and tag the item with labels.
  4. For a larger request, switch to the assisted breakdown and paste the request text into the description panel.
  5. Choose the provider and run the breakdown to get a table of suggested epics, stories, tasks and bugs with estimates.
  6. Review each suggestion, edit titles or estimates in place, and uncheck anything that should not be created.
  7. Confirm to create only the selected items, or discard the whole set and start again.

Who it's for

  • Engineers and developers working from a daily task board
  • Product managers translating customer requests into backlog items
  • Scrum masters and team leads grooming and estimating a backlog
  • Technical program managers breaking large initiatives into deliverable work
  • Support and solutions teams filing structured work from customer requests

Illustrations

3 illustrations of this concept. Select one to view it full size.

Task Board Section

The tasks section keeps the daily path to two entries: the board and a create action.

The task board page is shown while its content is still loading, with a spinner alone in the content area, which puts the navigation structure in focus. In the left rail the tasks entry is expanded to reveal two items: the board itself, highlighted as the current page, and a create-task action marked with a plus so adding work stays one step away. Beneath it the rail continues with sprints, reports, team, workspace and analytics, then a grouped list of shared workspace modules. The breadcrumb above the content traces home through the product and the tasks section to the page. The top bar keeps the organization, workspace and project switcher, a product switcher, a language selector, and controls for search, help, notifications, settings and theme. A footer below carries the wordmark and tagline, social links, and columns of product, resource and legal links.

Create Task Form

One card covers the whole item: description, classification, estimate, scheduling and labels.

The create-task view is a single card headed for task details, introduced by a subtitle describing adding a new task to the project backlog. Cancel and create actions sit in the page header. The card opens with a title field and a description area, both carrying example placeholder text, then drops into a three-column grid of project, priority and work type, with the priority and type dropdowns showing sensible defaults rather than forcing a choice. A second grid row covers story points, prefilled with a small default estimate, a sprint identifier, and a due date picker. A final field takes comma-separated labels, with example tags shown as placeholder text. The whole item is defined in one scrolling card with no tabs or steps, so a small task can be filed quickly while a larger one has room for detail.

AI Breakdown of a Feature Request

A pasted request becomes a reviewable table of epics, stories, tasks and bugs — saved only on confirmation.

The concept envisions an assisted breakdown as a two-panel view under the tasks section. On the left, a panel invites the user to paste a feature request or description; the text area holds sample request text about enterprise customers wanting to sign in through their own identity provider, with a character counter, a provider dropdown set to the platform default model, and buttons to run the breakdown or clear it. On the right, a suggestions panel carries an assisted badge with a suggestion count and a caution that nothing is saved until the user confirms. A table lists the proposed items with columns for title, work type, priority and an hour estimate, using badges for types such as epic, story, task and bug, with a pencil control for editing each row; the epic row has no hour estimate. Four of the six rows are checked, and the confirm button names that exact count. Run details and token counts sit beside a discard action. All content shown is sample data.

Topics

  • task board kanban
  • create task form
  • AI work breakdown
  • backlog item generation
  • story points estimation
  • epic story task bug
  • work item priority
  • feature request to tasks
  • agile backlog grooming
  • AI-assisted planning
  • sprint task assignment
  • work item labels

Related concepts

All PlanMagnet concepts
Get started freeBrowse all concepts