> Sprints have a very important operational dynamic, in that they set a fairly clear, achievable, short term goal. Lately, the trend with those using Jira in l

> Sprints have a very important operational dynamic, in that they set a fairly clear, achievable, short term goal. Lately, the trend with those using Jira in large organizations is to just "carry-over" what's not done in the current sprint into the next. And so instead of talking about why something didn't get completed, and how to resolve it quickly (move it to someone else, change the way it's done, postpone it until something else makes it easier), the work snowballs, with even more work getting piled onto the sprint. That's because while the dev team is agile, management deadlines often won't budge. The other problem is dependency upon another process/service internal to the organization that is not on your sprint cycle. Typically they have other, different priorities, which don't match yours. So they may get around to it eventually, which might mean a week to a month typically. I think Kanban is in someways vastly superior in these cases. You can still do "waypoints" at say every two weeks to see how things are moving along, but at some point if your company isn't "agile" then it really makes no difference if your team is.