Do agents think you're doing agile wrong?

 WARNING: this is an AI generated article -- but that's on purpose. Without any priming or preparation, I asked a chatbot about sprints and tickets, and got this as an answer.

The Question:

My team wants us to split up all the features into tickets and assign them at sprint planning, so they all have enough work to do and know what they'll be working on. Is this a good system?

The Answer:

Usually, no: making sprint planning a full assignment exercise tends to optimize for individual utilization, not team flow, adaptability, or delivering the sprint goal. Scrum guidance says sprint planning should define what can be delivered and how, but teams should keep enough flexibility to choose work as the sprint unfolds rather than pre-assigning everything up front.[mountaingoatsoftware]

Why it can backfire

Pre-assigning all tickets creates single points of failure when a person gets blocked, is absent, or finishes early and can’t easily help elsewhere. It also encourages “my ticket” ownership instead of shared ownership, which makes rebalancing harder when priorities change mid-sprint. In practice, teams often end up with a more brittle plan that looks organized but reduces throughput.[linkedin]

When it can help

There are a couple of cases where assigning more explicitly can be useful: very new teams, or teams that still need stronger individual accountability and clearer expectations. It can also be a reasonable short-term stepping stone if the team is used to a lot of ambiguity and needs a gentler transition toward more self-management. In those cases, the goal should be to reduce assignment over time, not make it the permanent operating model.[mountaingoatsoftware]

Better alternative

A healthier pattern is:

• Agree on the sprint goal and the subset of work you can realistically finish.[atlassian]

• Break features into small, clear tickets so the team can see the path through the work.[atlassian]

• Have everyone leave planning knowing what to start first, but let the rest be pulled during the sprint as capacity and blockers become clear.[mountaingoatsoftware]

• Reassign or swarm work freely if something gets stuck, instead of treating tickets as personal property.[linkedin]

Practical rule of thumb

If the main reason for assignment is “so everyone has enough to do,” that’s usually a sign the team is thinking in terms of individual busyness rather than flow. A better question is whether the sprint backlog supports the sprint goal and gives the team enough flexibility to adapt daily. If you want, I can help you turn this into a short, non-confrontational argument for your team or Scrum Master.[atlassian]

My Comments

The answer and the question both largely ignore the fact that people can work together and co-create software without handoffs and tickets and dividing work up. If you assign a feature to a team of five, you don't break it into one-person tickets and then mob up on each of those -- you slice work differently and not as small.

Notice also that it assumes that teamwork is only good for rescue situations, where someone is stuck. I've yet to see an LLM assume teamwork of any kind except as a rare exception. I don't know why. Teams have been working in mobs, pairs, and swarms for decades, but it only seems to rate as a "if you can't handle the work alone, then get help" situation. Odd that. This is perhaps because they're using Atlassian as a canonical source of information, and Atlassian is invested in a soloist, ticket-driven approach.

It is nice that swarming and flow at least get a mention.