Is there a sprint object?

Not today. There is a sprint-shaped workflow pack. A sprint as an object with dates is on the list and not yet shipped.

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.

No. Filters are saved views. Search returns an answer across tasks, projects, comments and files.

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.

Published September 15, 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-shaped pack runs backlog, selected, in progress, code review, QA and done. 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

A sprint as an object with a start and an end is not here; the sprint pack is a shape of stages. Labels, time tracking, and a code panel or diff surface are not here. GitHub is not integrated. Duplicate links between issues, beyond a dependency, are not here. JQL is deliberately not a language on this product; saved views and search are what exist.

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?: Not today. There is a sprint-shaped workflow pack. A sprint as an object with dates is on the list and not yet shipped.
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?: No. Filters are saved views. Search returns an answer across tasks, projects, comments and files.