Until recently my team had a very simple set up for our sprint board, with just four steps: Tickets would start as “To Do”, move to “In Progress” when somebody started working on it, then put into “Code Review”, and when everything looked good the code was merged and the ticket marked “Done”.
This worked well until we started to have issues with tickets after merging. A separate team was responsible for building a release and deploying it. As we started to put more tickets through we started to find occasional issues at this stage, either just before deploying or soon after. These didn’t go unnoticed for long — we regularly check all our features in production — but they did show that we needed to pay more attention to the work between merging it and deploying it.
The natural inclination of the team was to do what most other teams in the department have already done: insert a “QA” column between Code Review and Done, where we can test the final build for anything unexpected.
I wasn’t on board with this plan. I think it’s too easy to start thinking that QA only happens when a ticket is in that column. Even if everybody says they know that’s not true, the board can reinforce that idea anyway. Following Richard Bradshaw‘s cue, I tried to explain that QA is something that happens, or should happen, throughout development. The problem is, I didn’t have a good alternative name for that new column:
To me, “Testing” is just as limiting as “QA” (should I not do any testing when something is in code review?) “Verification”, the other candidate, to me seemed too narrow for what would go on in that column. I would have been happy with anything but “QA”. But I’m not sure I really made my point—or they took it too literally—because we ended up with this as our board:
And from there it was a small step to this:
This has had one delightful side-benefit: at our daily stand-ups, instead of asking if a ticket is done yet, we can now legitimately ask: “Are you a wizard yet?”
1 Pingback