It is sometimes difficult to get progress reports because it's difficult for the people who are doing the work to figure out where they are in the process. For example, imagine that you have some tickets; "Add create method, "Add delete method", "Add list method". You take the first ticket, and decide to add the RPC server, and the authentication infrastructure, and the test harness, and the CLI wrapper. What do you say on the progress update? "You've been working on this for a week, why isn't at least one of those done?" The answer is because the tickets are pieces of value that the business wants to ship (you can ship without delete, I guess), but it's not actually how the software is assembled. What happens is that someday, you say "I'm done with create" and then 2 hours later say "I'm done with delete and list". That makes execs feel like they're being misled, but it's true.

Of course, if you actually enumerate the "how" and not just the "what" in your ticketing system, you can get a much more realistic view. "Add foobar RPC server", "Hook auth into the foobar RPC server", "Add foobar subcommand to CLI", ...

I think everyone does better with a clear set of expectations, autism or not. That's why we do design docs, design reviews, and try to put a realistic set of work into the ticket tracker. I would say personally, though, 99% of the time I don't really need to do that to get a good result out of myself. I can just say "by next Tuesday I will have this subsystem done". Typically this is done with heroics rather than good planning (Monday becomes a longer-than-average workday), so I try to avoid it, but I definitely understand why people want a more freeform environment.

> (you can ship without delete, I guess)

And some management type will say when you're halfway through 'add' that they'll cut 'delete', but it's impossible to automate anything without a delete option, so you implement it anyway during your testing and then they get mad.