I'm working on a project loosely following the scrum model. We're doing two week sprints. Something I'm not clear on (and don't have a book to consult) is exactly what is supposed to happen between sprints: there should be some "wrap" process, where the product gets built and delivered, but:
- how long does this typically take?
- should the whole team be involved?
- does it strictly have to finish before developers start working on the next sprint items?
- is this when code review and testing take place?
There are three developers, adding up to about 1 FTE. So the sprints are indeed very short.
Best Answer
To make it clear: Your managers probably told you about Scrum but what you perform is not Scrum.
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.
Whole team must be involved in meetings mentioned in previous answer.
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.
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.