Simplify and visually optimize Kanban board
planned
Vidas
We are exploring options how to make Kanban board structure simpler on the looks as well as management. One of the options is to change how rows (swimlanes) are displayed and then also remove concept of status groups. Everything will be a status, you can even split status for structural purposes (just like it would be with status groups). See image attached. I wish to collect initial impressions and ideas whether this makes sense.
Vidas
planned
A
Alfredo Arpero
Late to the party, but I've needed time to digest what these changes were supposed to reflect.
Visuals: I personally like the visuals we have currently. My current workflow looks as attached. I'm not exactly sure how these proposed changes will help me. It seems the main benefit is in offering users flexibility and allow varying degrees of complexity for Kanban boards; my guess is that my style is so simple that it won't be impacted by these changes. Please let me know if I am missing anything.
Vidas
Alfredo Arpero: thank you, this is useful to represent broader use case spectrum.
W
Wim Verloop
Vidas it looks indeed quite clean. The way I use TH is with a lot of items having (a lot) of child items which again also have child items. A project with subtasks which are too big and are split up in child items for instance. Often, I want to work at child items of child items, so I move the specific "parent" to a status group so I can look at that kind of details. How will that work in this setup? Also, I use a lot of column colouring for readability of a more complex board, how will this be done? And will it be possible to colour the new swim lanes?
Vidas
Wim Verloop: color coding will stay as is. It is highly adopted and desired functionality in Teamhood.
Regarding expanded child items - we are still in research mode. As we see it, there are multiple scenarios how people use/want to use hierarchy:
- Child items as a simple 1 level checklist under parent card - already solved and works nicely
- Child items as standalone cards - now you need to move item to dedicated status to expand child items. Works nicely when people follow upstream/downstream Kanban. Does not work when people want to have child items flowing separately from their parents.
- Deeper child item hierarchy in Kanban - does not work ok because max 3 levels are visible on the board where 3rd level only when parent item moved to specific status. Flattening child items as standalone cards, could solve it a bit. But there would be no one centralized view of the whole hierarchy (for example, this is where List view is great. You can have as many levels of child items as you need).
- Child items completely living in a separate board, but still visible somewhere near the parent card.
- And probably at least one more use case which I missed.
Vidas
Marco Kollster Wim Verloop Giedrė | 2L Marie-Anne Herremans Matteo Musso Justas Makrickas Rodrigo González Vásquez Alfredo Arpero What do you think about such board structure?
M
Matteo Musso
Vidas The new visuals look clean! I'm not sure I understand the second part, what do you mean exactly about removing status groups? Could you elaborate some more? Do you mean adding the possibility of having a single flat list of statuses? Or what?
Vidas
Matteo Musso currently Teamhood offers status groups and statuses as structure elements. We think it can be simplified so that everything is status. Then user can decide whether to have a flat structure of single level statuses, or split statuses into sub-statuses and have deeper hierarchy which would mimic status groups. Does this make sense?
M
Matteo Musso
Vidas Ah now I see, I confused status groups, statuses, and sub statuses, since I always used them naively without paying attention to their formal name.
When thinking about statuses, what comes to mind is what you described in your answer to Wim Verloop earlier, specifically points 2 and 4 about child items and their now strong link regarding statuses.
Specifically, I'd like to have a parent that lives on a business level board, and children that live on an operative evel board. As of now I have to either have them tied together (which is worse for both cases) or have them as unlinked replicas.
But maybe this is out of the scope of this current undergoing improvement!
Back to what you are proposing, I think it's a positive change overall, to me personally I can see the benefit of the enhanced visual clarity, while I'm not sure how in my business case to benefit from the enhanced functionality, but I don't see any negatives, so I think it's a win-win
Vidas
Matteo Musso: thank you for taking time and sharing feedback. Regarding child items in a separate board - you can do that by creating synced copies of child items (a bit more clicking, but possible). I also do understand the necessity to have this as native and easy as possible. Would you create child items under parent and then move them to another board?
W
Wim Verloop
Vidas I am totally on the @Matteo way of using child items, so that makes (at least) two of us... :) The only inconvenience atm is that if I create a child item in the synced copy, it does not show up in the original item. If that would have been solved, TH would be perfect for my way of using it. But that's just me!
Vidas
Wim Verloop: just to be clear - you mentioned that synced copies do not stay under parent. That's should not be the case. Check this short video about synced copies, to see what I meant: https://youtu.be/lPz1fknT_Zw?t=639
W
Wim Verloop
Vidas No I am referring to my wish to have child items which are added to a synced copy show up in the item from which the synced copy was made. Am I clear like this? Or am I still talking gibberish?
Vidas
Wim Verloop: now I finally got it! It's about newly created child items to be automatically copied over. Thank you for being patient with my brain speed!