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.
First of I would not have hard rules about it; the whole point of scrum is to allow you to adapt to the situation. So you should be able to modify the sprint backlog during the sprint if you absolutely must (like you forgot something critical).
But saying this modification to the sprint backlog during the sprint should be resisted. The whole point of the sprint being short is that new work can be added to the next sprint (after it has been correctly prioritized) without affecting the overall project timeline (multiple sprints).
But if the work is critical for one of the tasks in this sprint you have two options.
- Add new item to the sprint.
BUT remove an equivalently sized item from the sprint.
- Drop the item that was badly planned from this sprint (so you can properly plan it in the next sprint).
- Adding in an alternative (of appropriate size) from the top of the product backlog (which should have be in priority order from your sprint planning meeting).
- Or when all sprint items are finished allow dev's to pick up slack from the product backlog.
So I am in the camp that you should probably not modify the sprint backlog. But you have to take into account the situation there may be exceptional circumstance. In most cases I would go with options 2 and let devs pick up the slack with tasks from the backlog.
Then in the next planning meeting the new task will be appropriately analysed and added to the sprint (as appropriate).
Remember the sprint is short and just the mark of the next drop not the end of the development cycle. The product owner would have to be very desperate for a feature that they could not wait for the end of the next sprint.
Best Answer
The sprint goal should be placed back into the backlog and then reevaluated along with all the other stories in the backlog. In most cases, this will mean it will be prioritized to the top of the backlog and pulled into the next sprint. In theory, if business needs have changed since the backlog was last prioritized, it could be left for a later sprint or even thrown out. But the key concept is that it is just treated like any other story in the backlog.
If this happens often, you need to reevaluate how you are writing stories as this means you may not be creating fine-grained enough stories to be finished in a single sprint. But the vagaries of development mean that it will happen from time to time to even the best team.
(I have seen some teams react to this situation by splitting the story into two at this point, the first being the work that was completed and the second being the new work required. I dislike this because I think it makes things look artificially good after-the-fact.)