The Sprint Board holds every issue in the current sprint. It reads as a list or as columns, and you can group it by priority, type, epic or label depending on what you are trying to see.
Columns can be added and removed, so the board matches how your team works rather than the other way round.
The nine issue types
| Type | What it is |
|---|---|
| Task | The standard unit of work |
| Bug | Something broken that needs fixing |
| Feature | New capability being built |
| User story | Work framed from the user's side |
| Improvement | Making something existing better |
| Tech debt | Work that pays down past shortcuts |
| Spike | Research, to learn before committing |
| Sub-task | A piece of a larger issue |
| Epic | A larger goal grouping related issues |
Spike is the one teams underuse. When nobody knows how long something will take, a spike is the honest answer: a time-boxed piece of research that ends with an estimate rather than a deliverable.
Tech debt is the one teams under-record. If it never appears on the board it never gets scheduled, and it does not stop existing.
What an issue carries
A description, sub-tasks, a linked project, an assignee and a tester, an epic or parent issue, labels, priority, custom fields, and its comment history.
The point of keeping all of that on the issue is that the reasoning stays with the work. A decision made in a chat thread is lost within a week; the same decision in a comment is still there when somebody asks why in six months.
Arranging it
Group by type shows the mix: whether you are shipping features or mostly fixing bugs.
Group by epic shows which larger goals are actually moving.
Filter by label or assignee narrows to one thread of work or one person's load.
None of these change the data. They change what you can see, which is usually the thing in the way.
Did this answer your question?
No, ask a person