> Sprints don’t help organize things… You can’t talk about sprints unless you talk about the sprint demo: It’s the proof that the closed tickets actually repre

> Sprints don’t help organize things… You can’t talk about sprints unless you talk about the sprint demo: It’s the proof that the closed tickets actually represent completed work. > … they’re designed for mangares who don’t trust their employees (if your manager needs to look at Jira to figure out what work you’ve done for your review or what’s shipped lately then they’re not paying enough attention to the team). That’s one take, but managers are just as likely as anyone else to B.S. their way through the tickets: “oh yeah that’s pretty much done”. The sprint demo clarifies what “pretty much” means. > … When you’re on [an efficient team]… then it’s easy to see how everyone else mistakes the bureaucracy around the work for the work itself. This is extremely true, and probably the main failing of any project management method. > … the backlogs, the sprints, the points—is pure bureaucracy. It gets in the way of productive folks… Again, we can’t talk about the sprint unless we talk about the sprint retrospective: It’s there to help the team identify tools and processes that are inefficient, and adjust incrementally through automation, elimination, or modification. One of the things that might get eliminated is the fixed interval sprint. Or replacing relative-size estimation techniques (“story points”) with something more rigorous. That “sprints” are used mindlessly is frequently true, but we should not dismiss them mindlessly either.