Ytdyklly

We are a DevOps software team with dependencies upon a release process which often requires us to wait before releasing some code to production for up to 5 times longer than our sprint length. This causes stories to either remain on our board or go onto a hidden board, neither are a suitable use case.

We have recently had a new board layout imparted upon our team. While our previous column layout was not the greatest, I have reservations about this new one.

While every team is different, I was hoping to get a critique of this board layout by anyone who might be sympathetic to the scenario above, and perhaps some advice on how better to lay it out. Our board columns are:

• Draft


• Awaiting Info


• Estimation


• Ready


• Work in progress


• Ready for testing


• Testing


• Testing failed


• Ready for deployment


• Complete


• Cancelled

11 columns is a lot and I would much rather use more standard agile terms. For example, Done and To Do are completely absent, here.

If I read this correctly, you are asking about your board / workflow design rather than the overall circumstances in Scrum, so I'll focus my answer on that.

First, when designing a workflow, especially more complicated ones like this, the benefit comes from matching your process. Since I don't know your process, I don't know how closely this matches it so I can't say if it succeeds in that regard. I can, however, identify a few common patterns I've seen elsewhere that you should consider.

Queuing Stages

As a rule, queuing stages are problematic because no one is doing anything in them. A big red flag that something is a queueing stage is that it starts with "Ready For". When we have queueing stages in our system, this means that either we want things to sit around with no one working on them (pretty rare), or we're trying to hide a bottleneck.

As an example here, you have a development stage followed by a testing stage. No action happens between the two so there should be no stage between the two. Typically when I see this in boards, it is so the developers can move faster than the testers, which is local optimization at the expense of global sub-optimization (or to take the jargon out, we slow down the actual completion of work to make ourselves look better).

If I want a visual indicator that something is ready to be pulled to the next stage, I usually recommend changing the card color or adding an icon in electronic tools and just a magnet or sticker on a physical board. Or, to be a bit more pedantic, team members could just talk to each other.

Short-lived Stages

I'll pick on estimation for this one. I'd be curious what value you get out of the estimation stage. Usually estimation is a quick conversation and when I see these in other teams, a lot of times the team is done with the task before they even remember to move the card. For most teams, "Work must be estimated" could just be a policy for a card to move from Draft to Ready. Of course, I could be completely wrong. It isn't common, but some teams benefit from robust estimation techniques that warrant this being its own stage. Your team needs to make that decision for themselves.

Testing Failed and Cancelled

These just feel odd to me. They feel like information more than workflow. I feel like I could just put a red dot on the card and completely eliminate the need for these stages entirely. My biggest concern when I see stages like this is that they are often used to set aside cards that would otherwise "look bad" on the board. Again, decide for yourself if these add value.

Final Thoughts

I feel like this board could be:

Draft - Development - Testing - Deploying - Done

and you could use other visual indicators to show the extra information. But, it's your board and you know what really happens in your team. When I coach teams, I usually say that I'll never tell them their board is wrong, but they should always ask themselves if visualizing their work in a certain way teaches them something they can use to improve how they work. If so, it is doing its job.