3 ms·
The flipside of course is that they HAVE to be discrete. My issue with sprints is that they arbitrarily reduce the solution space - instead of asking "what's t
by perrygeo 3y ago
The flipside of course is that they HAVE to be discrete. My issue with sprints is that they arbitrarily reduce the solution space - instead of asking "what's the right way to do this?", you ask "how much can we hack out in 2 weeks to show progress?". By putting a time/complexity limit on the work you choose to address, you are de facto ignoring any potentially high-impact work that doesn't fit into your sprint structure.
Performance optimization, bug fixes, architectural changes, dependency/infrastructure updates, developer tooling, database health, etc are rarely, if ever, prioritized in a sprint-centric workflow. Yet we know these things to be absolutely vital to the success of software.
- JohnFen 3y ago> My issue with sprints is that they arbitrarily reduce the solution space - instead of asking "what's the right way to do this?", you ask "how much can we hack out in 2 weeks to show progress?" I think this is the most common way that the concept is abused, and it's very, very easy to fall into this trap. I suspect that it comes from an idea that the sprint length is sacrosanct so having tasks that go beyond a single sprint is to be avoided. Sprints should be a planning tool, not a hardcore thing.