Software engineers learn early on that building stuff means taking little steps at a time. Once you get into the profession, that means tickets. Whether you’re doing Scrum or Kanban, your job consists of pushing tickets to the right.

Getting things done means flagging them as “done”. User stories, Epics, tasks. If you’re not closing tickets, you’re not working.

In the eighties and nineties, there was the dream of the Software Factory. Some group of smart people get together and negotiate the “scope” of the project. It’s the total body of work. You split up all this work into smaller pieces and when all of those are processed, the work is done.

Work-breakdown-structures, backlogs, requirements,… It has been given a lot of names, but the idea has remained the same: list the tasks before working on them.

All our planning tools are based on this. Every methodology contains some variant. The typical team standup is people listing the JIRA tickets they are working on.

Here is the thing: software isn’t developed ticket-by-ticket. It grows organically. It’s the invisible stuff in-between that matters.

Have you noticed how scope has the weird property of always getting larger? That’s why every project is late. Managers have made a career of fighting “scope creep”, but can’t stop that train from derailing. Why is that?

Why do stakeholders and developers keep adding things to the list? Is it because they want to squeeze the most out of it? Is it because they want to sabotage the project? Or could it be that the one who wrote the original scope document wasn’t really a fortuneteller?

But we’re Agile! We don’t do Big Upfront Design anymore! Do you have a backlog that contains “all the work”? Do you have Epics that make up the “total scope”? That’s BUD! It might not be as detailed, but it’s still the same concept. It’s the belief that you can define most of the total package upfront.

Software is developed the way a skill-set is developed. You experiment and learn in a certain direction until you see progress. If you want to learn how to cook, you will read a tutorial and experiment with a few dishes. You will not make a backlog that contains “learn about marination”. You don’t even know that’s relevant at that point. That’s not scope creep, that’s a backwards process.

But if we don’t have a backlog, we don’t know what to work on! How can we be productive? Take a look outside your development team and look at how other people are working. Is your HR department doing Scrum? Does your management board schlepp tickets from left to right? Of course not! They are still getting work done, no?

We’re doing pair/mob programming these days, but tickets can only be assigned to one person.

The best code is that which you don’t have to write, yet our team velocity goes down if we throw away tickets.

Who makes up these rules?

It’s the Software Factory. It’s Taylorism rearing its ugly head, a system to control the geeks. It’s the idea that software is a workflow that has to be optimized by managers. It’s not. It’s a creative process. It’s a garden, not a conveyor belt.

Tickets should be reserved for bugs and support incidents. For all the rest, we should trust our teams of professionals to build the right product.