Who performs a release and how is it estimated?

Question

I have just joined and become the Scrum Master for a team at a company. I came in on the last three days of one of its many sprints. On the last day of the Sprint, they released the increment. This took about five or six hours, coming across issues with the network, third-parties etc. to make it a lengthy process.

My question is, who performs the release? How is this normally estimated? Is there a separate task for it? What happens if it goes so slowly that it overlaps into the next Sprint?

Thanks everyone!

Answer 1

1. It is the task of the dev team.
2. not estimated separatelly since its a task, its taken into consideration when estimating the story
3. Team can create a separate task in the backlog, if the team feels that it helps them. 4. Story isnt done

Answer 2

who performs the release?

Normally, the release engineer. Otherwise it would depend of the competencies needed to do the release. You will find that the QA engineer could do it, or maybe a developer, a technical leader...

How is this normally estimated?

In my opinion, you don't have to estimate it. Because this is a recurring task in every sprint, with approximately the same kind of problems along the different sprints, it is already included in your sprint velocity

Is there a separate task for it?

This is a separate task for the doer but as a repetitive one, no need to include it in the sprint backlog

What happens if it goes so slowly that it overlaps into the next Sprint?

The same thing as what will arrive if a User Story is bad estimated. You would discuss about the problems in the retrospective and find together the potential solutions to them for next time

Answer 3

Usually a team self organises to work out who should do the release. In some teams there are team members that specialise in releases. Other teams share the responsibility around.

Typically I would not expect a team to estimate separately for a release. This is because in Scrum the definition of done often includes the release. Which means that the time taken for the release should be factored in to the estimates for individual stories.

It is quite common to have a task that tracks the release. However, this depends a lot on the effort required to do the release. Some teams have a very slick release mechanism and so do not feel the need to track releases as separate tasks.

As you rightly point out there is a risk that the release will be delayed for some reason. When this happens it can be very disruptive, both to the planning for the next sprint and to the business generally. Once again, if the definition of done for stories includes release then failing to release within the sprint should impact on the team's velocity.

I have seen a lot of approaches to releasing strategy. Some teams release on the last day of the sprint. Other teams release a day or two before the end of the sprint. It is also not uncommon for a team to have a staggered release so that work for each sprint is released in the subsequent sprint.

What this highlights is the importance of a quick and simple release mechanism. Automating releases can be hugely beneficial to a team. This is because it reduces the time that the team spends releasing and reduces the risk of disruption due to release problems.

It is worth considering making a business case for automating your releases. For example, say by automating your releases you can save 5-6 hours of effort per sprint. Over 10 sprints that would save 50-60 hours of effort and would also significantly reduce the risk of disruption. If the team was to spend 40 hours effort automating the release process then it would pay for itself in 10 sprints or less.