Sprints when used correctly are invaluable to a development team. Source: My own experience as a junior dev and a lead dev on teams working in this methodology.
Note it's not useful in all (most?) scenarios or in all stages of a product's development.
When you are in support mode for a product that's stable, standing up something from scratch, working on a POC or experimenting with frameworks or libraries - it's not useful, use kanban or something else.
But when you are working on a/b tests or adding features to an existing product it's extremely useful.
When done correctly:
You get a two-way promise between leadership and a dev team. The dev team commits to getting stuff done within that <sprint-length> time - therefore they must carefully decompose work where that makes sense. Leadership commits to LEAVING THE DEV TEAM ALONE for that <sprint-length> time - no priority changes, no "Product Manager Chad had a dream if we implement X we get 1000% more revenue!", none of that nonsense. This means for bigger efforts, you get <sprint-length> chunks of working code "done" at time. This in practice means the devs drive how much they can get done in a certain amount of time - if a PM wants an earlier date out the door, that's <x> fewer sprints of decomposed work that gets done.
The tricky thing here is the use of the term "correctly" above. Sprint-based methodology isn't a tool for management to dictate or predict performance and it's not a tool to micromanage tasking. If leadership DOES have this distorted view of it, then it is useless overhead to no benefit for anybody.
It's also not useful at all if only the dev teams practice it - everybody has to respect the commitments required to do sprint correctly - if they don't, use kanban or something else.
Note it's not useful in all (most?) scenarios or in all stages of a product's development.
When you are in support mode for a product that's stable, standing up something from scratch, working on a POC or experimenting with frameworks or libraries - it's not useful, use kanban or something else.
But when you are working on a/b tests or adding features to an existing product it's extremely useful.
When done correctly: You get a two-way promise between leadership and a dev team. The dev team commits to getting stuff done within that <sprint-length> time - therefore they must carefully decompose work where that makes sense. Leadership commits to LEAVING THE DEV TEAM ALONE for that <sprint-length> time - no priority changes, no "Product Manager Chad had a dream if we implement X we get 1000% more revenue!", none of that nonsense. This means for bigger efforts, you get <sprint-length> chunks of working code "done" at time. This in practice means the devs drive how much they can get done in a certain amount of time - if a PM wants an earlier date out the door, that's <x> fewer sprints of decomposed work that gets done.
The tricky thing here is the use of the term "correctly" above. Sprint-based methodology isn't a tool for management to dictate or predict performance and it's not a tool to micromanage tasking. If leadership DOES have this distorted view of it, then it is useless overhead to no benefit for anybody.
It's also not useful at all if only the dev teams practice it - everybody has to respect the commitments required to do sprint correctly - if they don't, use kanban or something else.