Agile - How to determine the appropriate length of a Sprint

The more the environment changes, the more the requirements change, the shorter the length of a sprint. This would help minimize risks and allow those changes to take place without messing up the frozen Sprint Backlog.

In my team we have recently adopted Agile.

Our first 2 sprints were getting used to the new team and the Agile process, so we don't count those. These along with our first official sprint were three weeks long.

The last sprint and this current one are two weeks long. We were told by our Agile coach to try different time frames during our first sprints to see the ideal one for the team.

Here are my findings:

1. We always have an extra "emergency" release at the beginning of the sprint. People always want things ASAP and this is not always (never, in my experience) with the sprint timeframes and we end up having a release at the beginning of the sprint.

2. In our case, with our ITIL process and Platform complications. Release Notes, UAT, test UAT (have users test and sign-off), Release Notes, Live release (testing one node at a time - clustered architecture) and notify users can take up at least 24 hours. All this takes up development time from the sprint.

I find two weeks is too short for such a changing environment and the time spent preparing deployments.

I find three weeks gives us a bit more breathing space.

Maybe the solution is to keep two weeks sprints. This way the business gets changes a lot quicker BUT we need to find a way to freeze our sprint backlog and avoid "emergency" releases mid sprint.