-
Suggestion
-
Resolution: Fixed
This should offer similar functionality to the planning mode for the Scrum Boards as in Using Plan Mode. For example:
- Display and estimate.
- Organising via Epics.
- Column Done status.
- Swim lane and cell constraints.
- incorporates
-
JSWSERVER-13690 Improve Prioritising of Issues in a Kanban Board
- Closed
-
JSWSERVER-15014 Add Epic Tab in Kanban Labs (Similar to Backlog in Scrum Boards)
- Closed
- is duplicated by
-
JSWSERVER-6373 Feature request: Drag sprints into version in Kanban Board (like Scrum Board)
- Closed
-
JSWSERVER-8433 As a greenhopper administrator I'd like to configure the fields displayed on the cards in the kanban rapid board
- Closed
-
JSWSERVER-8741 Allow pre-planning versions for Kanban board
- Closed
-
JSWSERVER-9875 As a Kanban user I want planning view
- Closed
-
JSWSERVER-12869 Ability to limit the issues shown on Active Sprint mode of Kanban Board
- Closed
-
JSWSERVER-13507 Epics in the backlog view of the scrumban board
- Closed
- is related to
-
JSWSERVER-7052 EPIC: Kanban Epics Support
- Closed
-
JSWSERVER-7833 Allow quicksearch for KanBan boards (Work mode)
- Gathering Interest
-
JSWSERVER-8724 Provide a kanban chart report and gadget that shows story points
- Gathering Interest
- relates to
-
JSWSERVER-7204 Epic in Kanban rapid boards
- Closed
-
JSWSERVER-8723 Provide Version management in KanBan plan mode
- Closed
-
JSWSERVER-11402 Ranking a new issue directly underneath the currently selected issue doesn't work on Kanban boards
- Closed
-
JSWSERVER-7992 Ability to see sub-tasks in the backlog
- Gathering Interest
-
LOLCATS-118 Loading...
- links to
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
Form Name |
---|
I know, this annoys us too. In our case, QA only tests Standard Issue Types, and not subtasks. Therefore an issue can only go live in a version if all its subtasks are resolved. So we make PRs only for the parent issue, and not for subtasks, as we can only merge the PR when all subtasks are done. Therefore it does not make sense to have a different fix version for subtasks.
I could imagine other workflows, but for our workflow it does not make sense for subtasks having a fix version field. It also does not make sense for Epics for another but similar reason - the epic versions are implicitly given by the versions of its contained issues - in a similar sense, the subtasks versions are implicitly given by their parent issues.