There’s an art and a science to creating good Agile Boards. As with any truly Agile endeavour, your board design should evolve over time in response to a continual inspect and adapt process, so in theory, whatever your starting point is, you’ll eventually end up in a good place, where the board is a decent model of your team’s work.

But of course the better your start point, the fewer iterations it will take to get into that sweet spot where your board really works, so let’s examine what a good start point might be.

Many teams are somewhat intimidated by more than a few columns on the board (especially to start with), and might not feel comfortable beginning with the kind of detailed workflow that I outlined here and here. And that workflow was for managing software development, which you might not be doing.

So here I offer a simple generic workflow that is a worthy start point for any team; and I really mean any team – there’s nothing in what follows that references software development, or any other technical work, so this could work for a Finance Team, for example.

Here’s how the lifecycle of a generic piece of work maps to these columns:

• A ticket describing a piece of work is created. This ticket has not yet been properly evaluated, and for all the team knows it could be anywhere on the value scale from “brilliant and/or extremely urgent idea”, to “complete nonsense that deserves immediate deletion”. Tickets in this “they’ve been created and nothing else meaningful has happened to them yet” state are in the Candidate column. Other names that work for this column are Inbox, Idea, the Jira default To Do – and you may have better names still.
• This next thing that needs to happen to a ticket is to flesh it out such that it is ready to be worked on in earnest. That fleshing out is captured by a column called Defining. At a minimum, an adequate ticket definition might be as simple as a one-bullet-point Definition of Done. It might require more, maybe much more – detailed Business or Technical Analysis, accompanying files of various types such as Spreadsheets, Process Flows, Mockups or Wireframes… it’s all contextual, and in this simple workflow it’s all done under a heading of “Defining”.
• When a ticket has been properly fleshed out – meaning that representatives of all the downstream functions (the roles that will need to work on the ticket later in its life) have agreed that what’s written in the ticket enables them to efficiently take on their portion of the work when the ticket lands with them – then the ticket is Ready to Start. This, technically, is a “buffer state” – it represents a gap between activities, rather than an activity itself.
• When the real meat of the work is under way, the ticket is In Progress. I actually don’t much like this term for a column, as every state between the first and last is some kind of “in progress”. For software development teams a better term for this state is In Dev, but for non-tech teams I’ve yet to think up a better name.
• Any non-trivial work should always have a second pair of eyes on it before it is presented back to the people who requested it; you don’t want to look a fool in front of your customer, after all. This is the Reviewing step. It’s might be performed by a peer of the person who did the work, perhaps by someone in the same role (eg one developer checking another developer’s code), or it might be done by a specialist function (eg QAs/Testers). As ever, such decisions are contextual; but that non-trivial work should be properly reviewed/checked is as close to a universal truth as you get, and that’s what this column represents.
• Finally, whoever wanted/requested the work (the Customer, or their proxy) needs to agree that they’ve got what they wanted (or near enough, dammit) before you can declare the piece of work to be “Done”. This is the Sign-off step, and in a well-functioning team should be unproblematic. After all, all that’s required for Sign-off is to compare (i) what’s been delivered with (ii) what was agreed would be delivered, and since (ii) is definitely written in the ticket (right?), and since you make every effort to regularly update the Sign-off people on progress (perhaps they come to your Stand-ups), there ought to be little in the way of controversy or surprises in this step. If a team is having problems signing work off, the root cause(s) are usually to be found upstream, often all the way upstream at the Defining stage, and need to be solved there.
• Hopefully I don’t have to go into great detail about what Done means.

So there you have a simple, generic workflow that’s a decent starting place for any team representing its work on an Agile Board, and may turn out to be fine longer-term too. Remember; this is all empirical, so inspect and adapt, keep what works, and change what doesn’t!