Hacker News Reader

Comment by mydriasis | Hacker News Reader

I like sprints because they're discrete. We agree to a certain bit of work that can get done in a certain period, and we do our best to complete it. It helps us to think about breaking up our tasks, and how tasks can be broken up. At the end of the sprint, we get to take a bit of a breath, and prepare for more upcoming work.

Kanban style means that it's just a marathon. There's no time to stop and take a breath, there's no time to celebrate anything that gets done, because the workstream is just infinite instead of divided.

That's my two cents, anyway.

View on HN

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.

> 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.

Yup, I'd agree with this. I enjoy the "cadence" of working with a team in sprints. In a previous role with a small team, it was good to look back on the past two weeks & call out the things in a group setting that had gone well, or hear about wins that I wasn't directly involved in. Just created a great sense of forward momentum which I personally found really motivating. If some process wasn't working well for us (including the way we ran sprints) then the next retrospective would only be a couple of weeks away & we could discuss if it needed changing then. By the time I left it felt like we'd got a really well-oiled machine going. That kind of frequent communication and sense of shared forward momentum is one of the things I actually really miss now that I'm working solo again to be honest.

In practice I usually see that when developers finish tasks early, then they don't just sit around doing nothing for the remaining 2-3 days, they pick up new tasks right away. This means there's never a clean "end" to the sprint, it basically just turns into Kanban with scrum ceremonies.

It's quite difficult to get an org comfortable with developers having so much downtime at the end of a sprint where they can spend those days focusing on other stuff.

Do you actually get to take a break or a rest when finishing the sprint work early? In 10+ years of doing sprints, I don't think that's ever happened to me or my team. In practice if we finish early (which is rare, maybe 1 in 5 sprints) then we try to jam in some refactor or performance fix or bug fix or something, and that ends up taking at least the remaining sprint time. There is never a chance to catch a breath.

No -- that's not quite what I meant -- more of a "logical break" in the work. A chance to come up to the surface and gasp a moment before diving back in for more on the same project or set of tasks because there was a clear breakpoint.

Reply on news.ycombinator.com