Nothing can be more frustrating from a developer's perspective than an “endless task”. A task that they grabbed from the “board” or they kindly received from a product person, or any folk related to the development context. Those tasks have a high destructive potential, destroying not only the developer's motivation but also any pipeline set to the team. The common mistake is to think that this behavior could be easily isolated.
From my recent experience mixing my contexts as a developer and manager. I got a chance to see it from the “other side”. I had previous experiences as a developer. But having both contexts I was able to see common patterns, and how this evolved during the development period.
Firstly I want to introduce the term I usually use, the Pitfall Task. A Pitfall Task usually is classified as a straightforward task, a little change, just a new functionality, and other terms. But they don't. The task starts simple, but a chain of events inside the code, or the iteration over the task extends the task by days or even weeks. And when you see it, some resources from your team are stuck inside a pitfall.
Some developers tend to insist on the task and try to perform their best without inquiry about the task requirements, or over the iterations. What a mistake. It's understandable, we want to show ourselves as highly productive persons. But what happens when an abstract layer of complexity starts to drag our expectations? Frustration, lack of self-confidence, and imposter syndrome are some of the words we can identify.
And that's why it's important to identify and act against Pitfall Tasks. A super condensed task, that could easily fragment into at least 4 other tasks, or even in an epic. A lousy-scoped task that changes in every iteration. An extra scope always appears after a review. An oversimplified task that touches on many application aspects and drags the developer to perform herculean work inside the codebase.
No matter if you are a developer or a manager, it's your responsibility to identify those tasks and try to overcome them in the best way possible. Communication is the key. For a possible pitfall task, let all the team know about it, including the product team. For someone that stepped into a pitfall (you included), overcome by raising the pain points and sending suggestions to improve the specification and set new expectations. But if you are introduced to a bad scenario, you need to fight against the Pitfall Task. Set personal expectations aside from the business scenario, and keep yourself motivated, a Pitfall Task only wins when you fall.
Pitfall Tasks need to be mitigated from our routines. Keep your pipeline clean and fun for everyone to work with.