I'm working on a project loosely following the scrum model.
To make it clear: Your managers probably told you about Scrum but what you perform is not Scrum.
How long does this typically take?
Sprint review meeting + Sprint retrospective meeting ends current sprint. In short sprints they should take something between 30 minutes - 1 hour together. Next working day starts a new sprint by performing Sprint planning meeting 1 and 2. Based on the team size and sprint length these meeting can takes 2 - 4 hours.
Should the whole team be involved?
Whole team must be involved in meetings mentioned in previous answer.
Does it strictly have to finish before developers start working on the next sprint items?
Yes because until review meeting is done you don't know if customer accepts result of previous sprint and you don't know what users stories will be committed in planning meetings.
Is this when code review and testing take place?
No. Code review and testing is part of sprint. Developers must do everything needed to deliver working code satisfying requirements. This can include code reviews and it always must include some sort of automated tests validating that code works and does what it is supposed to do otherwise the user story cannot be considered as done.
The main mental shift is with QA. Many developers think that QA is there to validate that code works and does what it is supposed to do. Definitely no. That is developer job.
QA should participate on product development. Their main responsibility in sprint should be communication with product owner and creation of automated acceptance tests for acceptance criteria (definition of done) which will validate that user story is really done and the application passes all new requirements. In small teams this can be responsibility of developers as well.
QA should also do some manual testing to keep product consistent and to discover missing features, validate user experience with UI, etc. QA is not there to hunt for bugs and regression testing - regression testing should be highly automated.
In my experience this is where most companies moving to agile fails.
If testing is separate from development, you have two -- separate -- scrum teams. It is a bad idea to have one hand work to the other.
Your developers must write their own tests, separate from this other team. You must treat this other "test" team as your customers.
In a sprint ... when do you release for testing ?
When the sprint is done. Totally done. That means you've done your own unit testing and are sure that it works. After your development team is done, you release it to other teams for "testing" or "deployment" or whatever else happens in the organization.
I guess my question is how to write stories that are implementable and testable.
That varies from team to team. The BA is part of the development team. You have to work on that as a team (BA plus developers) to get the right amount of detail. It's a team effort to get the right information from BA to the rest of the team.
How important it is to have automated UI testing for Scrum.
Essential. Completely required for any UI development. The developers must do all testing themselves before it is given to the "test team". If there's a UI, they must test it. If there's no UI, then automated UI testing isn't required. Testing is required, and a UI must be tested. Automated testing is the current best practice.
Bottom line. A separate "test" team and a BA who writes every little detail is not an optimal organization for Scrum. Scrum means you have to rethink your organization as well as your processes.
Best Answer
Sprints, indeed, depend on the days off. If you have ten day sprints, it's the same as having two week sprints if your team doesn't work on Saturday and Sunday.
This also means that you have to be very clear with everyone what does the duration of the sprint mean. If you tell that your sprints are ten days long, some people will understand it as two weeks, others—as one week and three days. Having a publicly available formal schedule such as:
may help.
The same goes with vacations, days off and other exceptional events (such as an important power outage in your office). If you know that two of the five members of the team are on vacation for the next three weeks, there are chances you won't perform as fast as usual during the next sprint (if you do, consider firing someone).
I would suggest two options:
Option 1
Keep two weeks sprints even during holidays (unless all of your team members are not working for the entire period of a sprint), but adjust the amount of work which should be done during the sprint.
Consider how many team members are available (some may be on vacation), how critical is their presence, how would their absence impact other people, what would go wrong (for instance, Joel is the only one who knows the password of the server, and he went to Himalayas for two weeks and will not be reachable), etc.
Move the sprint date slightly if major participants cannot attend the meeting. Doing it two days later or earlier wouldn't be too much trouble, but moving it a week towards or backwards would be an issue.
Also note that moving the date of the meeting may have a negative impact on some participants who may consider that the meetings are not that important than they are. You certainly don't want one of the participants to call you later telling that you should move the meeting from today to tomorrow, because he can't attend it today, because he has done another appointment for today.
I would probably find this option more intuitive. Keeping sprints regular ensures better visibility of the project, and keeping sprints short is essential. Unless the communication between the team members is excellent, a four-weeks sprint may have a negative impact.
Moreover, team members may not remember well what they did three weeks ago (especially after holidays). Personally, I can't even remember what I did yesterday; I can take notes, but if I know that the meeting will be only in four weeks, I will be inclined much more to skip notes as well.
Option 2
Make the next sprint much longer than usual (such as four weeks vs. the usual two weeks).
This approach is better in a case where you're sure that the progress will be too small otherwise. Having nothing to say during the sprint review and the retrospective may have two negative effects:
The team members themselves may have an impression that they "did nothing" during two weeks. In that case, they may be less motivated for the next sprint.
If the customer or your boss attends the meeting and has an impression that the team wasn't working too much, this could result in even worse consequences.