More Tickets Do Not Mean More Control

A Product Owner is preparing work for a designer.

There are Figma screens. There are stakeholder comments. There are legal questions. There are old notes in a Word document. There are missing screens, half-final texts, and a sprint that is already getting full.

So the natural move is to create a ticket.

Then another ticket. Then another one.

One ticket for collecting the screens. One ticket for changing the text. One ticket for the next screen. One ticket for the comment that came from a meeting. One ticket for the thing that is not final yet, but should probably move forward somehow.

It feels responsible. It feels like progress. It feels like the backlog is becoming organised.

But often this is where the work starts to lose its shape.

Because the problem is not whether we have a ticket. The problem is whether we understand the deliverable.

A ticket is not a substitute for thinking. It is only a container. And if we put unclear thinking into a container, we do not get structured work. We get unclear thinking with a Jira key.

That is not control. That is backlog noise.

The tempting mistake

The tempting mistake is to manage every small change as its own unit of work.

This is understandable.

When you are close to the work, the changes are what you see. A sentence needs to change here. A screen needs to be added there. A label is wrong. A flow has a different state. A message needs legal review. A designer needs context.

So the natural instinct is to task the visible pieces.

• Change this.
• Move that.
• Add this screen.
• Update that text.
• Create a Figma page.
• Then I will comment on it.
• Then we will create another ticket to implement the comments.

This looks practical from five centimetres away.

But from delivery distance, it becomes hard to manage.

The designer receives fragments instead of a clear module. The developer later receives output without the original reasoning. The tester has to reconstruct why something changed. The Product Owner loses the ability to say what is actually done. The project manager loses the ability to estimate the remaining work.

Everyone is busy. That is not the same as being in control.

The other mistake is the opposite

Of course, the solution is not to throw everything into one large ticket either.

That is the other classic move.

One giant discovery ticket. Everything inside it. ATS changes. Application flow changes. Profile state changes. Employer-side changes. Communication changes. Premium-related changes. Screens, texts, assumptions, questions, comments, decisions.

It feels tidy because there is only one place to look.

But in practice, it becomes a drawer full of cables.

Everything is technically there. Nothing is easy to use.

The issue with a giant ticket is not that it is long. Long can be fine. The issue is that it has no useful shape.

If a ticket contains several product areas, several flows, several decision points, and several handover paths, then it is not one deliverable anymore. It is a warehouse.

A backlog is not a warehouse. A backlog should be a map.

It should show what is changing, where it is changing, who needs to work on it, what done looks like, and how we will later check whether the original intent survived delivery.

Start with the module

The better unit is usually not the tiny change and not the entire project.

The better unit is the module.

An application flow can be a module. Profile application states can be a module. An ATS view can be a module. A landing page can be a module. A payment or invoice flow can be a module. A communication experience for a specific user group can be a module.

The question is not: “How many changes do I have?”

The question is: “Which part of the product needs to behave differently after this work is done?”

That is a very different question.

It forces you to think in delivery shape.

Not in comments. Not in screenshots. Not in scattered requests. In outcomes.

For each module, the ticket should explain the expected behaviour.

• What should be visible?
• What should change in the user experience?
• Where does the flow start and end?
• Which screens are in scope?
• Which screens are explicitly out of scope?
• What decision is still pending?
• Who needs to review it later?
• What will a tester need to verify?

These questions are not administration. They are project hygiene.

Project hygiene is like handwashing. It feels boring until you see what happens without it.

Figma comments are not the specification

Figma comments are useful.

They are good for pointing to a specific place and saying: this text should change, this block should move, this state should be shown differently, this screen needs another variation.

But comments should not carry the whole logic of the work.

A comment is local. A specification is structural.

If the only explanation of the work lives in thirty Figma comments, then the team has a traceability problem.

Someone will have to understand this later.

The developer will need to know whether the design is technically clear. The tester will need to know what the expected behaviour was. The Product Owner will need to know whether the intended user experience actually survived. Someone who was not in the original conversation will need to pick this up in two weeks.

That is where weak structure becomes expensive.

A good ticket can say:

This module is about the communication shown to users around potentially relevant candidates. The expected outcome is that the affected screens clearly explain the new candidate state, show the right distinctions between states, and support the user in understanding what happens in the background. The first step is to collect the affected screens into a dedicated Figma page. Detailed screen-level comments will then be added there, but the module-level expectation is already defined here.

That is very different from:

Please create a Figma page so I can comment on it later.

The second one may be a task. The first one is structured work.

Estimation needs shape

There is another practical reason this matters.

Estimation.

If we give a designer one large unclear ticket, we cannot realistically plan the work. We can only put a number on uncertainty and hope it behaves.

It usually does not.

The estimate grows. The scope grows. The comments grow. The handover risk grows.

Then everyone is surprised that the original estimate did not survive contact with reality.

But the estimate was never the real problem.

The work was not shaped enough to estimate.

If we ask someone to change a specific module, with a defined outcome and visible boundaries, they can respond with something useful.

• This is small.
• This is large.
• This needs legal input first.
• This touches another flow.
• This requires developer review.
• This can fit into the sprint.
• This cannot.

That is the point of the ticket. Not to prove that work exists. To make the work discussable.

Traceability is not bureaucracy

There is also a later stage we often forget when we are rushing.

Testing.

A tester does not need a beautiful history of our confusion. A tester needs to understand what was supposed to be delivered.

• What changed?
• Why did it change?
• Where is the final design?
• Which comments were resolved?
• Which decisions were made?
• Which module does this belong to?
• What was the original expected outcome?

If we cannot answer those questions without opening Jira, Figma, a Word document, Slack, and somebody’s memory, then the structure is too weak.

This is not a people problem.

It is not that the Product Owner is careless. It is not that the designer is difficult. It is not that Jira is bad.

Jira is only where the problem becomes visible.

The real issue is that the work was not shaped in a way that could survive handover.

The working rule

Before creating the ticket, stop for a second.

Ask:

• What product module is changing?
• What is the expected outcome?
• What screens, flows, or states are affected?
• What needs to be decided before implementation?
• What will the designer need to deliver?
• What will the developer need to understand?
• What will the tester need to verify?

Then create the ticket. Not before.

Small changes can still exist. Comments can still exist. Figma can still be used exactly where it is useful.

But the structure should not come from the comments.

The structure should come from the deliverable.

Because the goal is not to have more tickets.

The goal is to create work that can be estimated, delivered, tested, and traced.

Good project hygiene does not make the work slower. It makes the work survivable.