Interesting question @danashby around how many columns the board should have. Our team is just around answering questions at the moment, though we have 5 columns on our board too: Backlog, Next, In Progress, Done, and Closed.
I think I remember watching a talk about basically a 3 column board, where it gets rid of the traditional âReady For âŚâ columns, and merges them into the column to their right. And then it gets rid of QA, as QA should be happening at all points in the software dev lifecycle, and it basically just became something like Backlog, In Progress, and Done, or something like that.
I think there definitely needs to be a Backlog, but it might not need to be included on the board. All the ones Iâve used so far have always included one, but it might make more sense to not include it on a physical board, but do include it on the Trello one.
As for ET sooner, hmmm⌠I suppose in many ways, trying to analyse and uncover information in like the Analysis column and earlier could be considered exploratory testing, I suppose I just wouldnât have called it that, but I donât think youâre wrong. I have reworded my story #11 to call out exploratory testing in a less ambiguous way at least.
Iâd never thought about Retro Actions being cards on a board, but that totally makes sense. With that in mind, I think Iâd change the name of my In Dev column to just be In Progress instead. That way it doesnât actually feel as exclusive to development and can account for all the varying tasks that would want to be tracked on the board.
As for unrepresented work on the board, I think the In Progress rename would somewhat resolve that. The only roles I could typically see not necessarily being included are like POs or PMs, but I think that would probably be due to their remit being broader. And itâs not that they couldnât include the things theyâre working on in this, but as it might not be all specifically about the product in development, then it might just confuse or dilute things.
Ideally, I think stories would spend most of their time in either Backlog or In Production. Things should be flowing relatively freely between the middle columns, though blockers should be highlighted in stand ups. Out of curiosity, how do your teams handle blockers? If something is expected to be blocked for quite a while, are cards moved back into Backlog? I think in TW Iâve seen Blocked columns sometime used, or Iâve also seen them moved back into Backlog, but with little small post-its on them that signify theyâre blocked, and the card number thatâs blocking them.
Yes, so, I spoke to Usman who is one of our devs, and he mentioned that the Backlog column name was somewhat confusing, as a lot of the activities in there were mostly around Planning instead, which I agreed with, so Iâve altered the name of that to reflect. Overall, he thought Iâd covered all the activities well, but did mention Dev Boxing, which is basically along the lines ofâŚ
Say a story requires a new page to be created on a website, once the page has been created, but before they merge things back into the branch/trunk, theyâll get a QA to do a high level check of the page, to verify that itâs in line with ACs. So the story might not be fully completed yet, but they just want to ensure that things are as expected before bigger merges.
This isnât something Iâve come across before, but was definitely useful to know about!
I then spoke with Poppy our BA, and she had some additional suggestions that were useful. She agreed that most of the activities noted in the Backlog column were really around Planning, so I created a new column, and moved a number of them over into that. She also helped clarify some of the tasks on there to make them less ambiguous, and highlighted some of the most important things sheâd seen in previous projects: Highlighting dependencies, and drawing out how exactly to test stories during Kick Offs.
All round useful feedback!
