I've found success in cutting tasks up in things that will fit in a sprint. If I have to write a feature, I commonly split it into a few tickets: - Write the

I've found success in cutting tasks up in things that will fit in a sprint. If I have to write a feature, I commonly split it into a few tickets: - Write the code - Test the code - Documentation changes - Deploy the code If it's a big enough change (or a new app), I might create a few sets of those tickets. E.g. one "write/test/document/deploy" set for the database schema to do Y, another one for the business logic to do Y, another for the HTTP endpoints for Y, etc. The tickets are specific to the implementation, not to the feature, so they can't be expanded. New work can only come through new tickets, which get prioritized. Manager is happy because tickets get cleared. I'm happy because I can fight scope creep by pointing to my sprint and asking which tickets they want to bump for their new scope creep. Tickets like "implement X feature" with a 2 week estimate are a landmine for engineers because it's broad enough for the scope to expand infinitely, and it starts to look like nothing is getting done to management.