12

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.

Improve this question
3
  • 1
    As JW01 said, you should try to minimize the time between the sprints. It is a bad habit / imperfect process to always have some free time in between. However, one can always add more tests, start a GUI mock-up for the next sprint, maybe add useful comments to an existing bug. It is easy to get carried away though and start spending time on things that your manager will not necessarily appreciate.
    – Job
    Dec 15, 2011 at 23:30
  • 14
    What happens between sprints? LAN parties, obviously...
    – yannis
    Dec 16, 2011 at 4:27
  • Weekends, hopefully.
    – MrFox
    Sep 27, 2012 at 13:58

3 Answers 3

Reset to default
13

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.

Improve this answer
4
  • "No. Code review and testing is part of sprint." - cool, that's what I was asking. :)
    – Steve Bennett
    Dec 19, 2011 at 5:49
  • 2
    I think "must include some sort of automated test" is a bit strong. There's nothing that says the testing must be automated. In fact, in some cases it plainly can't. You may be developing a new style sheet and the "test" must be a visual inspection. You can't automate "does it look right?". Yes, tests should be automated if at all possible, but to say they must is overstating it a bit.
    – Bryan Oakley
    Sep 27, 2012 at 11:32
  • @BryanOakley: I agree. I targeted that part of my answer to only subset of development tasks where automated tests are possible.
    – Ladislav Mrnka
    Sep 27, 2012 at 11:50
  • 1
    This fails to answer the question.
    – Edward Anderson
    Apr 29, 2015 at 17:26
8

From my experience, there is no time between sprints, other than the weekend. Towards the middle of the sprint, the teams that I've been a member of work with the product owner to do some story grooming or preliminary sizings based on requirements. It's the product owner's responsibility to keep the backlog full - those stories are what the team will be working on, with some input from the product owner regarding priorities. Once the current sprint is done, the next sprint will start, utilizing the work that we've put in to prepare stories and tasks for the next sprint.

There is some overhead (lots of meetings, Q&A, and requirements evaluations), but overall it works - we make steady progress with little down time. Sprints have usually lasted either two or three weeks. QA usually takes place once stories are completed. However, the QA team might have other tasks that they can do. Regarding story grooming, tasks may fall to senior members of the team, or the whole team. It can vary depending on the size of the team and the process that's been agreed upon. Code reviews usually take place while QA occurs, or at the end of the sprint if time is compressed. And if there's not enough time to finish stories, in practice these stories get pushed to the next sprint. Proper sizing and estimation is very important here.

Improve this answer
2
  • Ok, so your QA takes place inside the sprint. When does deployment happen? Do you wait until all devs have QA'ed all their work, then one person deploys?
    – Steve Bennett
    Dec 16, 2011 at 2:30
  • We usually have at least two deployments - one at the midpoint of the sprint, and another at the end. More may be deployed to QA as stories are completed. Having shorter stories that can stand on their own helps a great deal. Larger stories are usually split into smaller ones. Technical stories that are required to get stuff working is usually signed off on by the dev lead/manager - QA doesn't get involved unless there is some output that can be tested (either logs, user screens, or other output).
    – JW8
    Dec 16, 2011 at 2:43
0

... and when is the estimation? planning?

Stories should be really easy to have no time between sprints.

And I don't know what kind of test are you talking but developers will make unit and integrations test, nothing more.

I was working in a project with sometimes 2 o 3 days between sprints and it feels right. Now I am working on a project where there is no time and its all fuzzy. The last time of the sprint we have production deployment and that takes some time of my last sprint day.

Improve this answer
1
  • In true scrum, devs typically don't write acceptance tests, but they can and should from time to time. Quality is the responsibility of the whole team. Even though there are (hopefully!) testing specialists, developers should pitch in a little. To say they do "nothing more" than unit and integration tests is not true SCRUM.
    – Bryan Oakley
    Sep 27, 2012 at 11:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.