An Agile Board is a model of a team’s workflow, the series of steps its work goes through from conception to completion. The first thing you have to get right (or rightish; boards will evolve over time) is the columns you use to represent those steps. In a previous article I discussed the background to such decisions, and in this one I will run through a hypothetical example.

One way to conceptualise a software development team is as a machine for converting ideas into fully tested working code in production that benefits real users of the system. That is, the input to this machine is ‘an Idea’ (=the very first step), and the ultimate output is ‘provably working code in production’ (=‘Done’, the very last step). Thus we have bounded the beginning and end of our workflow – now we just need to work out the stuff in the middle.

Idea

?

?

?

?

?

?

Done

Somewhere in the middle of this sits a critical state called ‘Ready for Dev’ (or R4D for short). This means that a ticket is fit for coding to begin on it, and it might take a lot of work to get an idea to that point. It neatly divides our total workflow into two; steps prior to R4D are about getting tickets ready, and the steps after that are about delivering that work. For reasons of length, this article will be about that first half, and a separate article will cover the delivery steps.

getting tickets ready					delivering
Idea	?	?	?	R4D	bla	bla	bla	Done

So let’s flesh out the steps between ‘Idea’ and ‘R4D’. What happens after you’ve had an idea? Typically there are vastly more ideas (=potential work) than there is capacity to implement them, which means that the next step after ‘having an idea’ is to pool that idea with all the other candidate ideas and do a ruthless selection of the worthier ones. The less worthy either get filed as ‘maybe do later’ or are thrown away. We need to represent this in our workflow with one or more steps that represent grouping / de-duping / trashing / prioritising the candidate ideas, a sequence that will be familiar to anyone who has organised a brainstorming session.

An Agile Board is a simplified model of reality, and it is possible to represent all these idea-processing activities that lead up to a prioritisation decision in just a single step on the Agile Board. This step might be called ‘Prioritisation’, but I usually call it ‘Triaging’, after the parallel process that happens in medical emergency units. The intricacies of Triaging will be covered in more detail here; for now it is sufficient to note the following:

• Triaging is synonymous with quick prioritisation
• you can only prioritise after you’ve done a minimum of grouping and de-duping (if a new ticket is a duplicate of an existing one, you just throw it away)
• the implementation of a ‘quick prioritisation’ decision in a tech team is to have slotted the new ticket into (roughly) its correct place in the ordered backlog of work for the team. When you’ve done that, you’ve finished Triaging.

The amount of information needed to triage varies massively from from case-to-case; sometimes a single bullet point might be enough, at other times considerable business and/or technical analysis might be required to make even basic judgements about the worthiness of an idea, and you have to put off Triaging until that information has been supplied. But whatever that minimum fleshing out is, in an optimally efficient workflow, that’s all you will have done at this stage.

That is because the result of a triage decision might be to do the work much later (potentially changing the spec considerably), or even not to do it at all, so any work invested up to the triage decision is potentially pure waste, and must therefore be kept to the minimum; limited resources should be focused on work which will definitely not be wasted.

getting tickets ready					delivering
Idea	Triaging	?	?	R4D	bla…	Done

The timing of the next step depends on how high or low a ticket has been triaged. If fairly high up the backlog, the next step may follow immediately. If low down, it may take a while, or even never happen at all. What is that next step, then? Since triaging often (correctly) happens on the basis of relatively little detail, now we have to flesh out the work in enough detail for efficient delivery. I often call this step ‘Ticket Prep’, and if teams have a role of Business Analyst, this step typically consumes a lot of their time.

How much detail is ‘enough’? Well, it might be adding a second bullet point. Or it might be large amounts of work involving a ton of people. It’s completely contextual, and depends on the team, the work itself, and the project / programme / organisation of which it is part. You can get ‘Ticket Prep’ wrong by adding too much or too little detail. Too much detail, the Waterfall Fault, can be a waste of effort – the future is uncertain and some stuff needs to be figured out in real time as it’s being built. But too little detail, the Agile=chaos fault, can also lead to waste – leaving the downstream people to frantically guess as to what’s the work is really about right in the midst of trying to deliver the bloody thing.

‘Ticket Prep’ is a kind of planning, and the idea that here is a sweet spot of how much of it to do up front applies to all kinds of planning. Mike Cohn popularised a graphical representation of this, the planning curve of diminishing returns. The sweet spot gives you decent reward for a reasonable amount of upfront effort.

Every team must find that sweet spot for themselves by an empirical process of trial and error. There are some tickets in some teams that must be specified up-front in pixel-perfect detail. There are other tickets in other teams at other times where to do so is madness, and the decision is multi-factorial. The easier it is to change the work later, the less crucial it is to specify every detail up front. How the team works together is also relevant; in strict BDD there needs to be a failing acceptance test before production code starts, and that requires quite strict definitions. The more developer-UXer pairs work together at the same screen during delivery, the less you need to specify up front. And so on.

Sometimes this single step called ‘Ticket Prep’ wraps a multi-faceted set of tasks that requires much expertise and many people. Sub-teams such as UX and Architecture may be extensively involved, and the assets they generate (eg architecture diagrams, wireframes, mockups etc) may be considered prerequisites a ticket to be R4D. These assets typically go through their own sub-processes of creation, reviewing and sign-off, and ‘Ticket Prep’ is sometimes broken down into sub-steps to take make this more visible on the Agile Board. But for this example, let’s keep all that under just the one step.

getting tickets ready					delivering
Idea	Triaging	Ticket Prep	?	R4D	bla…	Done

So surely, at the end of ‘Ticket Prep’, a ticket is ‘Ready for Dev’, right?

Well, maybe. You’d certainly hope so. Maybe the BA (or whoever) who wrote the ticket thinks it is. But getting this right is too important to gamble on; a team needs to check that a ticket really is R4D before it is declared such, otherwise you are potentially seriously messing up the delivery phase, and the lives of all your colleagues who will work on the ticket downstream. Every Dev and QA I’ve met has horror stories of the chaos (and probably late nights in the office) that ensued when they were obliged to start work prematurely on poorly-specified tickets.

So to avoid this waste, and to treat our colleagues with some respect, all tickets must be checked with these downstream people (typically Devs and QAs, though perhaps also other roles) in order to be declared R4D. All these groups have to collectively agree, with a real or virtual handshake at the end of a discussion, that a ticket is ‘Ready for Dev’”. Sometimes it might take 60 seconds to get that handshake, sometimes it might take a number of goes and a lot of revision and effort. But it’s less waste in the long-run to have those discussions before coding has started, than to wait till later and all hell has broken loose.

Does this mean every ticket has to go through a massive formal meeting with very single Dev and QA (and possibly others) invited? This is very unlikely to be a good idea, though it is, in fact, what Scrum mandates – Sprint Planning meetings are always whole-team meetings after all, and it’s in those meetings that Scrum tickets are supposedly brought to a ready state. But such uncompromising, universal rules are clumsy and wasteful, and while some tickets might justify the enormous man-hour cost of a big whole-group discussion (where you’ll probably batch up a ton of ticket discussions to try to justify that cost, thus making it a long whole-team meeting), many (most?) tickets certainly do not. Smaller, less formal meetings/chats might be better. Or you might be able to do it in writing – an IM chat, or in a Jira thread. It’s all contextual. Empowered teams decide such matters for themselves.

Exactly who needs to be in such conversations? It’s often enough to have representative(s) of each function that will deliver the ticket. Typically, at a minimum, this is one person from Product (often the one who wrote the ticket), and one each from Dev and QA, a triplet that is known as the ‘Three Amigos’. But perhaps for some tickets there are more than three; maybe UX want to be separately represented, so you have four. The architect has a big say in this ticket? OK, that’s a different mix again. Each team must figure it out for themselves.

So what do we call this step of getting the right people to agree that a ticket is R4D? Since it involves various ‘Amigos’, it might be called ‘Amigoing’. Or since it ends with a handshake, perhaps ‘Handshaking’ is a good name. Either way it is the gateway to R4D, the necessary check that Ticket Prep achieved its goal of putting the correct information into the ticket to allow for effective delivery downstream.

getting tickets ready					delivering
Idea	Triaging	Ticket Prep	Hand-shaking	R4D	bla…	Done

So this is where we’ve got to. We know the steps to get tickets from conception to a Ready for Dev state, from where it is safe for the delivery people to pick them up. We’ve made good progress, but have a long way still to go – what happens in Delivery is for another article.