At one company, we did do sprints, including retro and burn rates and all that, and none of the devs liked it. Bloody story point poker was a biweekly low-point

At one company, we did do sprints, including retro and burn rates and all that, and none of the devs liked it. Bloody story point poker was a biweekly low-point. Where I am now, we work with a mid-to-long term goal, split up in limited tasks and sub-tasks to reach that goal, testing task by task, and deploying whenever it's ready. That works much better for me. But it's a small team, so that may help. > Interruptions and unforeseen tasks will occur. That's certainly the case in my current job. Since the product is used for commercial projects, bugs and smaller problems crop up and need to be addressed, usually with priority. And my colleagues regularly need support because they messed something up. It takes a lot of time to make a product fool-proof, and it's nearly impossible to plan. So I'm in favor of incremental tasks in a larger design. Setting artificial goals and deadlines, which often won't be met, is only a source of frustration, not progress. But getting a larger design done in this way really requires that one person has the oversight.