Ticket farming starts when activity replaces flow

Some teams do not look like they have a delivery problem.

The board is moving. Tickets are being split, assigned, refined, commented on, estimated, carried over, closed, reopened, and linked. Stand-ups happen. Sprint reports exist. Someone can always point to a dashboard and say: "We are busy."

Then the release is late.

Or the feature is technically done but waits for review, test data, security approval, product clarification, another team, a deployment window, or a decision nobody owns. The organization keeps producing evidence of motion. Customers see little change.

This is what the current practitioner phrase "ticket farming" is trying to name. It is not a complaint about Jira. A ticket can be a useful coordination object. The problem starts when the organization treats ticket movement as the work itself.

You can see why this happens. Ticket systems are visible. Flow is less visible. A manager can count closed issues in seconds. It takes more effort to ask whether the right work reached production, whether quality improved, where the queues are, and what blocked learning.

The system drifts toward what is easy to inspect.

The trap: activity is cheaper to measure than progress

Nicole Forsgren and colleagues proposed the SPACE framework because developer productivity cannot be reduced to one number. It has several dimensions: satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. Activity matters, but it is only one slice.

Ticket farming happens when that slice becomes the meal.

A team that closes many small tickets may still be slow where it matters. It may have long review queues. It may push unfinished risk downstream. It may split work so finely that nobody sees the whole product problem anymore. It may optimize for clean sprint reports while the delivery system gets heavier.

The 2026 CircleCI State of Software Delivery report points in a similar direction, with limits. CircleCI is a vendor, and its data comes from CI workflows, not the full socio-technical system. Still, its public analysis of more than 28 million workflows is useful as one signal: feature-branch activity rose, while median main-branch throughput declined. In plain language: more work appeared to be happening before integration, but less work was making it through the path that matters.

That is the activity trap in one sentence.

Good Scrum was never ticket administration

The strongest research anchor here is Verwijs and Russo's "A Theory of Scrum Team Effectiveness". Their work combined 13 field studies with survey validation across 4,940 software professionals and 1,978 Scrum teams. Their model does not define effective teams as teams with clean boards.

It points to five factors: responsiveness, stakeholder concern, continuous improvement, team autonomy, and management support.

Now compare those factors with a ticket-farming system.

Responsiveness becomes harder when work sits in hidden queues between analysis, development, review, testing, and deployment. Stakeholder concern weakens when Sprint Reviews become demonstrations of completed tickets instead of learning with users, customers, or internal operators. Continuous improvement weakens when retrospectives keep naming the same blockers and nothing changes. Autonomy weakens when teams are fed pre-chewed tickets and judged by throughput. Management support weakens when leaders ask for status rather than removing constraints.

The issue is not the board. The issue is that the board becomes a substitute for thinking.

A simple diagnostic for delivery leaders

If you lead delivery, you do not need a new transformation program to detect this. You need a few sharper questions.

Start with this one:

What percentage of our "done" work changed something for a real user, customer, operator, or stakeholder?

If the answer is vague, you may be managing internal completion rather than external value. This does not mean every ticket must be a visible feature. Technical work matters. Risk reduction matters. Refactoring matters. But the connection should be explicit. "Updated API connector" is weaker than "support can sort failed submissions by date without asking engineering". The second version carries stakeholder concern. The first may only carry task completion.

Second question:

Where did work wait after someone had already done their part?

This is where Reinertsen's flow thinking becomes practical. In product development, queues are often more expensive than people admit. Work waits for clarification, review, environments, approvals, dependency teams, release slots, or decisions. Ticket farming hides this because every local step can look productive. Flow work exposes it by treating waiting time as system data.

Do not ask only "who is blocked?" Ask where the system creates waiting.

Third question:

What did we learn that changes how we work next week?

This is the antidote to ritualized retrospectives. If the same impediment appears every sprint, the team is not inspecting and adapting. It is documenting pain. Verwijs and Russo's model treats continuous improvement as a core effectiveness factor, including psychological safety, shared learning, concern for quality, and useful retrospectives. A retro action that never changes the system is another ticket in the farm.

What to stop rewarding

Be careful with incentives. If you reward teams for closed tickets, you will get closed tickets. If you reward utilization, you will get calendars full of work and queues full of waiting. If you reward predictable reports more than honest risk signals, people will learn to make the report look calm.

Replace activity praise with flow questions:

• What reached production or a usable stakeholder environment?
• What got smaller?
• Which queue shrank?
• Which dependency was removed?
• Which quality signal improved?
• Which repeated blocker did management help remove?

These questions are less comfortable than asking for ticket counts. They move the conversation from local motion to system performance.

The Monday morning move

Pick one active initiative. Not the whole portfolio. One.

Map its last 10 work items from request to usable outcome. Mark every wait state. Mark every handoff. Mark every reopen, clarification loop, review delay, and blocked decision. Then ask the team and the relevant stakeholders to look at the map together.

Do not start by blaming roles. Start by naming queues.

You will usually find that the team was not lazy, resistant, or "bad at Agile". It was operating inside a system that made ticket movement easier than value delivery.

That is where a good Agile Coach, Scrum Master, or Delivery Manager is useful: not by polishing the board, but by helping the organization see the work, reduce WIP, shorten feedback loops, protect quality, and make management support concrete.

The test is simple.

If your delivery system produces more artifacts than outcomes, stop asking people to farm the artifacts harder. Change the system so finishing real work becomes easier than reporting motion.

Sources

• CircleCI. (2026, February 17). The 2026 state of software delivery. circleci.com/resources/2026-state-of-software-delivery/
• Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., & Butler, J. (2021). The SPACE of developer productivity: There's more to it than you think. Queue, 19(1), 20–48. doi.org/10.1145/3454122.3454124
• Noda, A., Storey, M.-A., Forsgren, N., & Greiler, M. (2023). DevEx: What actually drives productivity: The developer-centric approach to measuring and improving productivity. Queue, 21(2). doi.org/10.1145/3595878
• Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. Celeritas Publishing. search.worldcat.org/title/435994279
• Verwijs, C., & Russo, D. (2023). A theory of Scrum team effectiveness. ACM Transactions on Software Engineering and Methodology, 32(3), Article 74. doi.org/10.1145/3571849