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!
