Over the years I've tended to like to work in a very specific way:
prioritized and documented requirements.
sit down with users to discuss and refine.
build small. test small.
quick iterations.
daily stand ups our nice for getting to know what's going on. helps the team find blockers.
everything should be a task. if you can't get it done in 4-8 hours it's too big of a task create a task to break it into smaller bits.
if you're connecting to another system build tests to verify their system is online and working. Why this isn't a thing when publishing an api is beyond me.
priority and requirements should be constant in the middle of a sprint.
developers shouldn't be coming up with test data.
the team and management should understand the value of QA as a second set of eyes and a different way to interpret the specs.
leave enough room in the schedule for support and other outside issues.
schedule tasks for technical debt and other improvements that improve the long term values of the system.
some tasks have a high chance of failure and that's ok. some experimentation is good.
extra points: add post mortems to improve the system. also, post mortems need follow up to make sure tasks are added.
so any variation in this kind a gets annoying.
don't get me started on smart objectives and other wish lists that aren't broken into manageable tasks and added to a sprint.
