Sprint planning or Release planning?

If you're reading this, you have used agile or at least want to try agile. We like to call ourselves an agile team or at least try hard to become an agile team. It just makes you feel more productive. However, even with all those agile success stories read on the internet, teams don't get where they want to be.

It starts with a promise of quick results cutting down development time. We fill up backlog with list of things to do and start planning sprint. Sprint one, what are we going to do? Its better to plan couple of sprints to make sure we know what's coming next.

Alright, sprints planned, lets say tasks were all completed. At the end of sprint 1, you might do a retrospective, congratulate ones who did well and blame ones no longer belong to the team.

At the end of Sprint 2, you might want to get back to product owner and get more tasks. You'll check list of bugs, improvements your team want to make and integrate awesome new plugin you found. As usual, you'll put tasks into new sprint based on priority.

We go on in this fashion and everyone seems to be comfortable. We are now agile team, we plan sprints, we do daily scrum meeting and retrospective. But how do you get these work into production? Do you release every day? After every sprint? So how do you version them?

Issues we faced was even though we were planning sprints, it was hard to release them because a part of what is usable would be spread across multiple sprints. As soon as you decide to put all tasks in sprint 1 into version 1.0.1, you'd find out there is something in sprint 2 that needs to be there for that feature to be usable. In some cases, someone would be on leave and before releasing 1.0.1 we'd like that feature to be there. Hence we wait another sprint for release. In a nutshell, we had to plan sprint, release and versioning separately and it was a challenge to keep them aligned. It was really hard to say we've deployed 1.0.1 till sprint 3 and starting sprint 4 we work on 1.0.4.

Questions: why do we really plan sprints? Is it because the books say so or is it because others do it? And most importantly what are we getting out of a sprint?

Brainstorming: How about we plan release instead of sprint? Instead of saying I'd like to implement login system in sprint 2, wouldn't it be better if we say I'd like to release login system to targeted users in Release 1.0.2? The tasks are prioritized would be the same and the type of tasks we put into the sprint would be same. Only different is the way we think about it. So the team's task is not to finish sprint 2 but to produce a releasable solution to the listed tasks that can be used by end users in release 1.0.2.

So when you plan a sprint, question shouldn't be what should we do next, it should be what do we want to release next.

By planning release instead of sprints

1. Every task that's worked on is released.
2. Priority of a task is determined by what end users want.
3. Before moving on to next release, team know what they've worked on is released. So there is sense of achievement as well.
4. Knowing whats released helps team be careful because whatever is being currently worked on is guaranteed to be released. Hence quality of work improves.
5. You can't work on something just because you want to.
6. Less burden on developers as unrealistic tasks or goals cannot be set
7. Easier versioning as each sprint is a release
8. Happy product owner.