For some engineering tasks, the work and the planning are almost the same thing. Once you've explored the problem, the code is the small part.
When asked to estimate, the answer is "I'll let you know when I'm getting into it". Then you're made to do a 'spike', which is indistinguishable from doing the task. Except do it in a day now. So the Engineer thrashes around trying to figure it all out in a day, and comes up with some number. The planning phase is now over, so they're supposed to just execute, regardless of what (bogus) number they found. So they start. At the end of the sprint, they've done less than if they'd just started the task the first day. They get 'measured' as a low performer. Of course its the process that's performing badly, not the Engineer. They get frustrated, resentful and stop cooperating with the scrum master.
I've seen this so many times at so many places its just exhausting. No amount of discussion can convince the evangelical Scrum experts that something is wrong with the process.
In agile, the estimates should be decided by consensus of the whole team. Requiring a single engineer to come up with an estimate is a smell.
Here is a quick 4 step planning meeting process based on planning poker:
1. Pick story from backlog, explain in a couple minutes what do you think would take to implement it.
2. Team members pick an estimate of the effort.
3. If there is consensus, note estimate on story, pick next, goto 1.
4. If there is no consensus on estimate, have highest and lowest explain why they picked their estimate, goto 2.
If you are expending more than 5 minutes on a story and there is no estimate, push it down and move on. It's not ready for development. The whole planning meeting should not take more than 1 hr.
This process, allows everybody involved in development to have an idea of the overall project and chip in with their experience to impact estimates (this might require refactoring class X, it might be hard to test, will conflict with Y and Z, etc)
And that's where the 'incremental tasks with no architecture' part comes in. When the scheduler needs rewritten to support whatever robustness; when the server feeds need to be redundant; maybe only 1 team member has any real idea what it takes. Coding isn't always about putting up another web widget or making another database entry.
That's the point: while there might be just 1 team member with a clear understanding of the effort, everybody gets to pick an estimate based on their own knowledge of the subject matter, even if they know nothing.
The exercise of just enumerating in a couple minutes all the steps to complete such a story gives everybody, including the one who is going to do the job a clear idea of the effort or whether they need more information before proceeding.
Btw, while Scrum is great for software development, they are not ideal for maintenance and/or infrastructure management where a defined process such as waterfall might work better. Trouble tickets and bug fixes should be kept outside the sprint unless they become stories.
Again, for a simple story where everything is known, sure. But some stories are all about figuring out how and what. The actual doing may be simple. The Scrum process fails.
When asked to estimate, the answer is "I'll let you know when I'm getting into it". Then you're made to do a 'spike', which is indistinguishable from doing the task. Except do it in a day now. So the Engineer thrashes around trying to figure it all out in a day, and comes up with some number. The planning phase is now over, so they're supposed to just execute, regardless of what (bogus) number they found. So they start. At the end of the sprint, they've done less than if they'd just started the task the first day. They get 'measured' as a low performer. Of course its the process that's performing badly, not the Engineer. They get frustrated, resentful and stop cooperating with the scrum master.
I've seen this so many times at so many places its just exhausting. No amount of discussion can convince the evangelical Scrum experts that something is wrong with the process.