Read on Twitter
People working in teams that use sprints: the point of having sprints is agreeing on deliverables, and then actually delivering them at the end of a sprint, right?
(This is a genuine question, not a snark. That *is* the point of chopping your work into sprints, no?)
(This is a genuine question, not a snark. That *is* the point of chopping your work into sprints, no?)
I& #39;m afraid I picked a bad medium to ask this because Twitter makes it impossible to link several reply subthreads, but I& #39;ll just try tagging everyone in this follow-up who responded to the original question.
@JensBoman @talli_gema @scanepa @ashinclouds @OldCrowEW @gherlein
@JensBoman @talli_gema @scanepa @ashinclouds @OldCrowEW @gherlein
We appear to agree that that is indeed the intended purpose of sprints. Now suppose you were part of a team that has cans it keeps kicking down the road.
That is, you have tasks that are added to sprint after sprint after sprint, and while you absolutely do work on them, they are not completed over months.
In that case, rather than just scoff and call that terrible sprint planning, would you agree that it& #39;s worth considering that maaaaaaaybe sprint planning isn& #39;t suited for the work you& #39;re doing?
I ask because I& #39;ve been in a similar situation with a team I ran. We ended up ditching sprints. Because we found them to be useless in operational work, which was a significant share of what we were doing at the time.
We use a Kanban approach now, which is a much better fit.
We use a Kanban approach now, which is a much better fit.
But it seems that a lot of teams are locked in the "thou shalt use sprints" dogma so much that they don& #39;t even look into whether sprints are a sensible thing to structure work around.
Thoughts?
Thoughts?
