The Problem with Tickets 

Tickets don’t add up

In a way, tickets are like paper shredders. In other words, you took an idea that made sense as a whole - one that had a lot of interdependence - and then you shredded it apart into smaller work assignments under the assumption that everything will come together magically if everyone does their part. 

Tickets are not modular 

Very often teams treat custom once-off software development projects as if they were modular assemblies but modular assembly requires you to deliberately construct every interface. Isn’t the definition of modular that you have a boundary with an extremely, clearly defined edge that is robust to all the different ways that you would try to connect something to it.  When Ikea designs furniture assembly designs, I'm pretty sure they put a lot of work into creating something that can be modularly assembled and will ultimately come together. I don't think it works the first time. So what happens is the work goes through the paper shredder, everybody picks up their individual shreds, and then, and then there's an assumption that all the shreds are going kind of come back together again in the end, but they don't go together.  It’s a mistake to think that we can kind of define a ticket and then work on a ticket basis when most of the hard work is the integrations between the things that we write in the tickets - how all the pieces fit together.

Little correspondence between tickets and real work (i.e. real vs. imagined tasks)

The tickets very rarely correspond to what somebody's spending their time on. Pick a random point of time during the week and go talk to somebody about what they're doing and try and trace that back to a ticket.. You will get responses like “ I started reading this ticket last week,”   It's almost like there is a black market of real work that appears alongside the official market of the work as described in the tickets.  The correspondence between tickets and work isn't real. In Shape Up, I talk about the difference between imagined tasks and discovered tasks which means the work that we imagine we have to do upfront rarely corresponds to what we're actually spending our time doing

Use pitches instead of tickets

Traditionally tickets were used as a starting point - the input we give people when the cycle kicks off that says, 'this is the work that you are in theory going to be doing'. We no longer use tickets as a definition of the work - we find packages (an upgrade from the pitches  we described in Shape Up) to work much better. A package is a description - a kind of guided tour of the project. It describes what you're really doing. So the process we use these days is we discuss the kind of shaping and then we package the work that was shaped in a package. The package works instead of the ticket as a starting point of what a person is supposed to do.

How to use tickets.

Tickets can still be used but they should be created by the team amid a project as a reminder of what to come back to later.  Whenever you set out to do something in code, you bump into something that you realize you're going to need to remember later or do later. Mature teams know they need to capture this somewhere (less experienced teams think they can keep it all in their head or get the easiest thing done first, and then all those things later, then it kind of come back and bite them). They should thus use a ticket system as a  method of capturing discovered work and maintaining an overview of kind of what's outstanding based on all the things that we discovered along the way. This way if we want to find out all the things that are outstanding (and actually need to happen), someone can produce a list. This list will allow us to see if the things that we're bumping into are like little things that we have to remember, or if there's actually a significant amount of unexpected scope that's accumulating or whatever. There's a variety of ways to do that, but I wouldn't be too prescriptive there.

Conclusion:

I find it best to leave it up to the team how they track the work they do inside the time box.  I cannot influence it, even if I try. This applies for the ticketing process as well. One should give the team a project, not a task. The team then gets to work. They create tickets for any tasks they discover along the way so one can keep track of outstanding tasks. Using this method, the tickets only contain real tasks - not imagined tasks.   

The Response: Experienced CTOs Weigh In

We asked members of the alphalist community what their thoughts were about this new way to see ticketing.  Does it work? Should it work?  

Better Fit for Experienced Teams Than Juniors

Lars Klein, CPO of Bots and People,  believes that the described approach to tickets can work, but may be difficult for those new to the job. 

Multiple Teams Each With A Different Approach

Dr. Franzi Löw, CTO at Localyze agrees with the article and shares that their team uses a variety of approaches to tickets. 

• Team 1 starts working on the project and creates tickets on the fly and without estimations. 
• Team 2 plans milestones and tickets for the next 2-4 weeks using t-shirt sizing. 
• Team 3 is somewhere in between.  The teams can choose their own ways of working based on some core principles. They differ in seniority and the most senior team is the one with less planning ahead.

Hard To Implement in Traditional Business Setting

Rupert Rockinger, VP Technology at Nielsen, believes that empowered teams can optimize capacity, throughput, and time-to-market/product-market-fit, but notes that a high level of agility may not always be compatible with traditional business processes that expect a higher level of predictability.