So, a scrum sprint is a fixed time period during which a specific set of features should be implemented. And a scrum team consists of all the people committed to delivering those features, the majority of them typically being developers and testers.
Having established these rules, one might wonder how to keep all of these people busy during the whole sprint. At the beginning of the sprint there is nothing to test yet, and at the end of the sprint there is typically nothing or very little left to develop/fix.
I've seen 2 approaches to handle this, but neither of them seems to properly solve the problem.
1) Let the team members decide what to do whenever they're out of tasks.
- If what they do is not thoroughly planned (i.e. major refactoring, switching to new testing framework), their work may turn out to be useless or be stuck halfway through
- On the other hand, planning such work can take plenty of time, and the client may be disappointed to see the team waste time on something that does't bring immediate value
- Such tasks usually can't be thoroughly estimated, so it's quite easy for unprincipled workers to spend their time watching YouTube cats without it being reflected on the scrum board or anywhere else
2) Make room in the sprint only for development, and start testing after the sprint is finished (when developers start working on the features from the next sprint)
- While developing features for the current sprint, developers get distracted by fixing bugs from the previous one, and they can fail to perform the amount of work that was estimated to be done during the current sprint
- Two scrum boards are needed: one for the current sprint features, and one for the previous sprint bugs
So my question is: how to properly distribute work during the sprint between developers and testers so that no-one gets overloaded with work or ends up without tasks at any point? Are there ways to improve the approaches described above? Or are there any better approaches?