Release Planning – the Second Iteration

We had a plan, we made the plan but we weren’t able to follow due to various reason. It turned out after 6 months that it simply doesn’t work. Product Owner does not want us to sit on already developed features, business want them as soon as possible. No release cycles, no special sprints anymore, just pure scrum. We are trying to follow what the Scrum guide says, we fail some times, we’ve failed many times but we never give up.

Houston, we have a problem, how the release should be scheduled?

Scrum guide still does not help too much: at the end of each sprint a potentially shippable Increment should be created, so a Product Owner may choose to immediately release it.

What about the release planning?

Release planning sessions need not produce a detailed release plan for the entire project. The release plan can be updated continually as relevant information is available.

How does our release plan look like?

PO presents the most important features which must be released to the scrum team. The team assigns release numbers or versions to the individual stories which are the building blocks of features. So the team has a rough plan about the upcoming release. It might be changed or updated at any time during the sprint. In time, ETA (estimated time of arrival) gets assigned to the release version once the team knows more about the completion date because the release might happen in the middle of the sprint.