Why do column constraints for issue count exclude subtasks?

David Yu
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 26, 2011

Perhaps I'm using GreenHopper incorrectly, or misunderstanding Kanban, but why does GreenHopper only include "Standard Issues" (no sub-tasks) with column constraints?

I see someone else has a similar query:

https://jira.atlassian.com/browse/GHS-2592

2 answers

1 accepted

0 votes
Answer accepted
Nicholas Muldoon
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 27, 2011

Hi David,

Valid question. At the time we figured that folks would want to limit the stories that were WIP while having the flexibility to use sub-tasks as required (and it was easier, technically, to implement this). Kind of weird in hindsight.

On the Rapid Board today you will see all issues included in the issue count for a column. While the Rapid Board is still in Labs we are targeting kanban teams. I would like to invite you and your team to give it a try and provide feedback. More information can be found here.

Thanks David.

Regards,

Nicholas Muldoon

David Yu
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 27, 2011

Thanks for the answer Nick. I'll see what I can do to customize our GreenHopper to display subtasks for now. :-)

0 votes
Arnold March 24, 2022

Although this question was posted back in 2011, it's still a valid question today (2022)

And I can augment the answer given from an Agile Coaching perspective who helps clients get Jira and Agile harmonised.

here are my thoughts on the subject:

The principle in these modern ways of working is to try to bring about 'team' dynamics:  everyone trying to align to a common unit, 'The Team'

'work is given to a team, not a set of individuals'

 

So in the Scrum Boards and the Kanban Boards, this is the principle followed.  The main Work Item (identical to Scrum's 'Product Backlog Item') is the sticky-note on the wall - or the Jira Issue - and it's this that delivers value and delights at least one stakeholder or customer when it arrives in 'done' (see Wikipedia's INVEST mnemonic:  V = Value)

Sure, teams sometimes pull the main work items to themselves, but the skilled coach may still try to implement a ways of working pattern known as 'swarming' : during the daily 24h planning conversation where the next 24h plan is formed (search for 'Agile Planning Onion' online) - and this is called the 'Daily Scrum' in Scrum, but Agile Kanban teams will do this too - we 'focus on idle work, not on idle workers' and we walk the board - in a 'pull' way of working (see YouTube's 'Resource Utilisation Trap' - Henrik Kniberg of Spotify Model fame covers 'pull' simply) - and we stand in the 'done' column, look back to the first populated column, look down (because it's an ordered queue of work, most value-delivery potential Work Item at the top) and 'swarm' : 'Who can do what over this next 24 hours on this Work Item to move it into the 'done' column or at least help it further on its way?' says the facilitator - and then let the team form a plan for that Work Item.  Repeat down the column until the team is at capacity and then everyone gets on with their days' tasks.  And if there is still spare capacity within the team, they're free to continue to look at the next populated column to the left and start at the top and contribute towards those work items too (so an item in the Backlog queue might get 'pull'ed into the 'In progress' column as the team has now begun work on that Work Item)

 

---

Optionally, individual team members can make use of Jira's sub-tasks.  (The word 'task' does not appear in The Scrum Guide;  it's optional.  Kanban teams is ever more lightweight and it's also optional)

Some teams and their members make use of sub-tasks, others don't : the whole purpose of the team is to get the main Work Item - which delivers value - into the 'done' column

---

I've even had 1 team where one team member enjoyed Jira's sub-tasks on the board, and another team member preferred to write her contributing tasks on her physical notebook.

---

It's the main Issue / Work Item getting into that 'done' column that is what is needed : this applies whether using sticky notes on a spare piece of wall, or a digital version of that such as Jira's Boards.

And given a Scrum team's 'Sprint Backlog' (the 'Active Sprint' in Jira) is also a Kanban board, this principle applies to teams that choose to use Scrum or teams that prefer to use more continuous flow (and in fact, you can have a blended approach and have multiple boards to serve the specific purpose you want to accomplish:  I've used Scrum Boards with Kanban Teams to exploit the Version Report for the algorithmic prediction, and I've also used Kanban Boards with Scrum Teams to reveal Cumulative Flow over time.

 

---

I've done this (e.g. in a role called 'Agile Delivery Manager' but I just behaved as a (true) Scrum Master.   Work 'flow'ed across the workflow into the 'done' column (Product Delivery Flow by Reinerstein, and also in Kniberg's YouTube video 'Resource Utilisation Trap' : and 'it just worked' :)

Suggest an answer

Log in or Sign up to answer