1

I've been working in "Agile" for a while and am working to move more towards agile at a new company. One of the problems I have always sort of encountered is effective integration of QA within the sprint.

We've done better at getting stories to QA earlier and shortening that feedback loop, but in the example of a 2-week sprint it was always inevitable that the last stories would get to QA late in the sprint, so QA would finish testing within the sprint but what does the developer do? They're done and have delivered all their stories, short of anything coming back from QA/UAT. How do we ensure they aren't just twiddling their thumbs for the last day-2 days of a sprint?

Kaitlyn2004
  • 111
  • 1

2 Answers2

2

Developers and QA should both work up until the end of the sprint.

Developers can spend the last day/few hours working on QA feedback, performing their own unit tests, reviewing or refactoring code, etc. assuming there is not enough time to pull in any stories from the backlog.

QA will of course spend the last time in the sprint testing, with any feedback at the end carrying over to the next sprint.

If there truly is nothing to do at the end of the sprint, people can take a well-deserved long lunch, maybe start gathering thoughts for the sprint retrospective, or high-level planning for the next sprint. Reviewing code (developers) and retesting (QA) never hurts either.

Eric King
  • 10,876
  • 3
  • 41
  • 55
  • 2
    I think on top of that if they still have nothing to do there is probably always some "sprint zero" tasks or research that can be done. Maybe you had to spike in the next sprint to find out more about a tool that the team has little collective experience in? Maybe you want to expand the capabilities of your CI environment? – maple_shaft Feb 25 '15 at 17:03
2

If you're doing it right, the development load towards the end of the sprint should be lighter. If it's not working, development are flat out fixing bugs and trying to get stories closed.

Some options are:

  1. Preparation for the next sprint. I like the team to have a good idea about what is likely to be in the next sprint and be thinking about the stories and likely tasks. That way sprint planning is not one big surprise to them.
  2. Innovation days - pick a relevant topic, research and present on it. This can work if it's guided and can be a good chance to push the product forward and also give developers a chance to shine.
  3. Developers execute test cases - teams are supposed to be cross-functional, right? If there's a QA bottleneck, why not have the whole team work to shift it?
Dan Saunders
  • 900
  • 5
  • 9