Is there a sprint object?

Yes. A sprint has a name, a goal, a start and an end, one of them is active per project at a time, and everything outside a sprint sits in the project's backlog. Closing a sprint carries the unfinished items to the next one or back to the backlog, and records which of the two it did.

Does the release gate block the transition?

Yes. An approval stage opens the approval on entry and refuses the exit until a decision is recorded.

Can a story contain tasks?

Yes. An epic contains stories and a story contains tasks. That hierarchy is built into the work item types.

Tasked supports a bounded JQL-compatible query subset over registered task fields. It is not full Jira JQL; saved views still store validated filter trees, and natural-language search works across tasks, projects, comments and files.

Can code be reviewed in Tasked?

A diff or a patch that somebody uploads can be, line by line: a note is anchored to the lines it was written on and comes back beside them. There is no connection to a code host, so no repository, no branch, no pull request and no commit.

Software teams: bugs, stories and a release gate

A software change in Tasked is not a card with a colour. Bugs carry severity and steps to reproduce, stories carry acceptance criteria, epics contain stories, and the software pack ends in a release approval the engine will not let the work leave without a recorded decision. Code review can send the item back to in progress with the label changes requested. QA can hold it until the acceptance check is done. None of that is a plugin.

Updated September 16, 20266 min read

The types a software team actually fills in

A bug asks for severity as blocker, major, minor or cosmetic, the steps to reproduce, and where it was found. A story asks for acceptance criteria and story points. An epic asks for a goal and a target date. Custom fields extend any of them when the team needs more.

The hierarchy is built in: an epic contains stories, a story contains tasks. That is shown in the interface, not left as a naming convention.

Bug: severity, steps to reproduce, found in
Story: acceptance criteria, story points
Epic: goal, target date

Four packs, one engine

The software pack runs intake, triage, in progress, code review, QA and release approval, then done. Intake and triage each carry a 24-hour window. In progress carries 72 hours. Code review is a review stage at 24 hours. QA is work at 48 hours. Release approval is an approval stage at 24 hours, owned by product, with in progress as the rework stage.

The sprint pack runs backlog, selected, in progress, code review, QA and done, and a sprint is also an object on the project: a name, a goal, a start and an end, one of them active at a time. There is no approval gate on that pack, on purpose: a sprint that closes into done is a different shape from a change that must be signed off. The bugfix pack runs triage, reproduce, fix, verify and released. The release pack runs cut, staging, sign off, production and notes, with sign off as the approval.

Transitions that refuse

A card cannot leave intake or triage until its checklist is done. Code review has a path back to in progress labelled changes requested. QA cannot enter release approval until the acceptance check is done. Release approval cannot enter done until the decision is recorded. A request for changes at that gate returns the item to in progress.

That is the difference between a board where anyone can drag a card into Done and a workflow where Done is allowed.

Honest gaps for software buyers

Four of the gaps this section used to list are closed. A sprint is an object with a name, a goal, a start and an end, one active per project, and a backlog of everything outside it; closing a sprint carries the unfinished items to the next one or back to the backlog, and records which of the two it did. Labels sit on the item and filter every view. Time is logged as typed entries against an item on the day the work was done, and adds up to a personal week and a project total against the estimates. A link between two issues is typed: relates, duplicates or clones, with blocking left to the dependency the workflow already reads.

What is still missing is the code host. A reviewer can mark lines in a diff or a patch that somebody uploads, and the note comes back beside its own lines. A code panel is not here: nothing in Tasked shows a repository, a branch, a pull request or a commit, and GitHub is not integrated. A Gantt chart with dependency arrows is not here either. Tasked supports a bounded JQL-compatible query subset over registered task fields. Saved views continue to use validated filter trees, and the product does not implement Jira's full grammar or functions.

The public API uses scoped keys. Webhooks come with a delivery log. OpenAPI and a developers page describe the surface. Those are on the Business plan.

Questions that keep coming up

Is there a sprint object?: Yes. A sprint has a name, a goal, a start and an end, one of them is active per project at a time, and everything outside a sprint sits in the project's backlog. Closing a sprint carries the unfinished items to the next one or back to the backlog, and records which of the two it did.
Does the release gate block the transition?: Yes. An approval stage opens the approval on entry and refuses the exit until a decision is recorded.
Can a story contain tasks?: Yes. An epic contains stories and a story contains tasks. That hierarchy is built into the work item types.
Is there JQL?: Tasked supports a bounded JQL-compatible query subset over registered task fields. It is not full Jira JQL; saved views still store validated filter trees, and natural-language search works across tasks, projects, comments and files.
Can code be reviewed in Tasked?: A diff or a patch that somebody uploads can be, line by line: a note is anchored to the lines it was written on and comes back beside them. There is no connection to a code host, so no repository, no branch, no pull request and no commit.