Sizes, batches and tickets

A week ago, two colleagues were discussing about batch-sizes in our company chat. Since then that topic is on my mind and now it's time for me to sort some things out.

As a consultant for Kanban and Scrum I am often asked about ticket sizes. As user of Personal Kanban I have to think about sizes of tickets as well. I have made some observations since I work with teams using taskboards with some kind of tickets and with me using Personal Kanban for myself.

Most of the teams I have met have some kind of maximum size they accept to work on. For the Scrum teams it was always either 13 or 20 Story Points. If they ended up with an estimate that was higher, they all had their ProductOwner cut the Stories into pieces they could handle better. For the Kanban Teams there was not a magical number but they still had a feeling of "too big". When I realize I have a task that doesn't move on my Personal Kanban board although it is urgent, I almost always find out that the chunk was too big to swallow - I just don't begin with the work as it feels too big and that simply isn't fun.

On the other hand, there are cases when I am asked if a task/story/ticket should actually be on the board as it taskes almost longer to maintain than to finish. When I actually put every little task on a board that may mean I go through a lot of trouble to write them all down and maybe I don't have even enough space. The cost of time for writing some small tasks is bigger than writing one batch-task.

So that leads me to the conclusion that a ticket shouldn't be too big or too small. But how am I to find out what too big/small means?

In at least three of my teams we radically reduced the maximum ticket-size at one point in time. Every time that felt ridiculous at first. And the teams asked for the actual value to the customer of one story/ticket. Sometimes there was no direct value for the customer for some of these small chunks. Nevertheless we tried it out. Some things became obvious very fastly:

1.     The small tasks cried out for vertical ticket-splitting. We found ways to develop very thin cuttings through the whole system (Walking skeletons, see Growing Object-Oriented Software, Guided by Tests), which actually had some value.

2.     We encountered less problems with "exploding" tickets where we find out bit-by-bit that our estimate is way off and the time needed is a multiple of what we were expecting.

3.     We found less tickets which could be worked on by only few people because of lack of experience.

The last two observations are due to the clarity that comes with the splitting. The smaller the tickets are, the less information can hide from you. So even less experienced people can work on the tasks and the chances are higher that you won't encounter problems which hide in the dark. These effects made my teams faster, even if the actual estimate rose by splitting!

Indeed I never encountered a team (so far) that felt the need for bigger stories in the end. When they succeeded to reduce the average ticket size, they sticked to it or reduced it even more. My recent teams had stories with the size of about two days of work in average and felt well with that.

When it comes to Personal Kanban, I seldom have the need for "customer value" or clarity as I normally am the customer myself and already know most of what I have to do. I have other needs for reduced ticket sizes. In my last blogpost I already wrote about motivation. When I see a ticket "prepare data for taxes", it just never gets done (at least it didn't for the last 4 months although it is still the most important task of my stationary board). The same as with "tidy up". For tidying up I actually break that nasty ticket down to about 20 (!) tasks like "hoover up bedroom floor", "tidy up big desk", "wash the dishes" and so on. Yes, that may be a lot of work to write them all down. But there is so much motivation in moving a task from DOING ot DONE, that I actually do them all in a row without hesitating too much.

My recommendation for ticket sizes is: Try out smaller sizes. Even if maintaining them may take some work. Try it out for some time before you decide if the sizes are really too small. Especially when tickets are often unclear, tend to drop out of the estimate or are unmotivating.

Note: You can break the stories/tasks/tickets down just before you want to work on them. Otherwise they might clutter your board. You can bundle them up in batches until it's their time to be worked on. The others stay in batches.