Why we stopped sprinting
I am neither scrum master, nor agile coach. But I have 10 years of experience working in more or less agile projects — and I want to share some of my learnings.
In this blog (others might follow) I want to talk about sprints — and why we stopped using sprints in our project.
First, some words on how we do understand agility (in terms of agile software development).
For us agility means incrementally delivering the right value at the right time to our customers in a sustainable way.
We adapted our working model to support this. For a few years we are now working in a kind of ScrumBan — best of Scrum and best of Kanban.
We like to have epics, stories and tasks (as part of stories but also beside stories) — we like daily standups and retrospectives, we like reviews, we do refinements — but not in the chains of a sprint.
We meet once a week to do what makes sense in terms of planning and prioritizing our work — sometimes it takes half a day — sometimes it takes one hour. If we need to do a re-prioritization in between, we do it in our daily standup.
If I look back at the times when we used Scrum (or what we thought Scrum is) situations like the following come to my mind:
Bargaining with the product owner
“This story needs to go to this sprint”
“But we are already over our velocity”
“We cannot wait for 2 more weeks”
“Ok, so what should we remove”
“We can’t remove anything” … resulting in
“Is this really 5 story points? If we interpret AC x a bit different, isn’t it a 3 then? Or if we do test automation for it next sprint?”…
Lots of discussions, lots of burned energy, no value… because, you might believe it or not — decreasing story points or overcommitting the sprint did not impact reality — a 5 was a 5 and the sprint goals were not reached. Or we reached it, but not in a sustainable way: Low test coverage, no skill transfer in the team, no updated documentation — instead of sustainable software, technical debt was created.
Unplanned effort
You can’t plan everything when you start your sprint. Incidents will happen, team members might get ill, urgent requirements might occur…
We started having a “baseline” story for unplanned effort. But this also did not help. If there was an urgent request which took more time, we had to re-plan.
“This request is 5 story points, so we need to remove something equal to 5 story points”
“So remove story A”
“But we already started story A and we would need to adapt the sprint goal” “Hm — but we need to do this”…
Very agile… very valuable…
Delivering at the end of the sprint
No special memory regarding this — besides that it seldom happened. Now we deliver when it makes sense. Having a good CI/CD pipeline with high test coverage and focus on keeping it up to date instead of “reaching the sprint goal” allows us to release/deliver more or less instantly.
The sprint is defined
In my very early Scrum experiences the sprint was written in stone. Also the acceptance criteria of a user story was a kind of law. We did the stuff, even if it did not make sense.
Now — if we figure out that a story does not make sense, we discuss and delete it. If an acceptance criteria does not make sense, we adapt it. We do not need to re-estimate the story, because we do what makes sense with reasonable effort. If we change anything, we discuss it.
Conclusion
I think our teams feel more freedom since we don’t sprint — because what we do is more like a continuous endurance run.
If we need something equal to an one hour task from a different team and we get told
“The sprint just started — we will put it to our backlog for the next one” meaning
“expect not earlier than 4 weeks” — we sigh and hope that we do deliver a better service…
This is just my experience. This is what works for our teams.
It might not work for yours— because there are different people, different products and a different setup.
But in my opinion you should keep in mind what you want to achieve, reflect your working model and adapt it to your needs.
