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?

  • 9
    You seem to be falling for the utilisation myth Mar 1, 2016 at 9:59
  • 1
    @holdenmcgrohen How are the estimates done - planning poker or something else?
    – Robbie Dee
    Mar 1, 2016 at 11:13
  • 3
    Testers should be writing test cases on day one. All they need to do that are the stories. If developers have significant down time during the sprint, it means you are not taking enough stories in. Plus, presumably if your testers are good, they are keeping your developers busy with bug reports near the end of the sprint. Also, ideally, you have the top few stories in the backlog fleshed out, so worst case, developers can work on one of the top couple in the backlog. Mar 1, 2016 at 14:48
  • 1
    @holdenmcgrohen, we also face similar issue in our project. We have started adding Stretch stories(should not be ‘must have’) as part of sprint and is only picked when developers are out of tasks. Now this approach help us in keeping tester's busy in starting days of next sprint. Mar 2, 2016 at 0:34
  • 1
    Remember that in most sprints you are selecting a subset of tasks from a backlog. If you complete everything you committed to, you get a head-start on the next sprint by starting to work on more items from the backlog -- just as if you run over, you pull fewer items from the backlog in the next sprint do you can finish the ones that weren't finished. Dump dogma; realize that the purpose of the tool is to serve you, not for you to serve the tool.
    – keshlam
    Mar 2, 2016 at 2:01

4 Answers 4


At the beginning of the sprint there is nothing to test yet

Really? You have no requirements to validate? No discussions to have with your customer? No wire-frames to evaluate? No test plans to think about?

at the end of the sprint there is typically nothing or very little left to develop/fix

I have never been in that place in a project. No more work to do? There is always something. Are all your tests fully automated? How is your CI looking? Could the database access layer be refactored to be simpler? And I've never worked on anything with an empty bug list and backlog. What did your developers used to do in a waterfall testing phase?

I know some people get very religious about what is and what is not 'SCRUM'. I couldn't care less about that. But I think you have two issues here:

  1. A 'traditional' QA department that test code once it is 'finished' by developers rather than working with customers and developers to make sure you are building the right thing as well as building it right. Take a look at the agile testing quadrants by Lisa Crispin. The best testers are involved in every stage of the software development lifecycle and the best developers write their own tests.

  2. Trying to stick too closely to a SCRUM timetable of 1 week / 2 week sprints without having a prioritised and sized backlog that is split down into tasks that are easy enough to complete within a short amount of time within a single sprint. If you had this then there would always be more work to get on with. Maybe the last feature you work on in this sprint doesn't get in to this sprint's release, but it can always go in to the next one.

Aside. If you have a small cohesive team then the roles matter less. Instead of having someone with the label tester who isn't allowed to write production code, or someone labelled a developer who thinks they are above testing, everyone should be doing whatever is necessary for the team to succeed, including the dreaded project management tasks when they are necessary, this is called a cross functional team.

One extra point brought up by @Cort Ammon in the comments. The agile manifesto talks about customer collaboration over contract negotiation. You say that:

the client may be disappointed to see the team waste time on something that does't bring immediate value

It can be difficult to explain and I understand customers can be very difficult at times but this would be a big red flag for me. They are trusting you with their source code / client relationship / business / whatever you are developing for them. If they can't trust you to act professionally in their best interest then either you have a problem or they do.

I have written a post that talks about software developers not being considered professionals. A professional doctor, lawyer, civil engineer faced with a client who changed the requirements on them part way through would not just reduce the quality and moan about it. They would tell their clients that it would be a problem. If the client pushed then a professional would not just blindly do it to a dangerously inferior standard because they would be liable. We don't take professional entrance exams and so are not liable. That doesn't mean we shouldn't try to be better.

In summary, I wouldn't worry too much about trying to get people to be more efficient at the beginning and end of a sprint but rather see it as a symptom of a wider issue within the team. Have you heard of eXtreme Programming (XP). I'd say the principles from XP to apply here are communication and respect:

  • Respect your team to do what they think is best. I would argue that if there is a lot of watching cat videos then either you have poor developers or you are treating them poorly.
  • Communication. If your developers are talking to each other, to the testers, to management, to the customer, then everyone should probably have a good feeling of what is up next and if they don't then they can just ask.
  • Yes, yes and yes. Spot on answer in every way.
    – David Arno
    Mar 1, 2016 at 12:19
  • Good answer - the last paragraph needs work. Raise and explain the points here rather than pointing to some tome.
    – Robbie Dee
    Mar 1, 2016 at 12:31
  • 1
    What did your developers used to do in a waterfall testing phase? - I didn't mean to compare scrum to watefall, but rather to kanban-like approaches, where there's always a to-do list of features that are already evaluated and prioritized. The scrum backlog contains features that weren't properly examined by the team, so if a single developer (who currently has no features to work on) decides to start implementing one of them in the middle of the sprint, this can lead to unexpected consequences. Mar 1, 2016 at 12:47
  • @holdenmcgrohen fair enough. My estimation is always terrible, which I try to account for, so I always like to have something up next. I think daily standups and pairing can help here, if your developers aren't left alone for too long they can't stray too far.
    – Encaitar
    Mar 1, 2016 at 12:53
  • @Encaitar Great stuff +1
    – Robbie Dee
    Mar 1, 2016 at 15:04

The first point is that Scrum is all about optimizing the team, not each individual. If the team is productive and efficient, it doesn't matter much if someone is idle at the start or end of the task.

However, on every team I've been on, there is always plenty of work. Let me address a couple of your specific concerns:

At the beginning of the sprint there is nothing to test yet,

While that may be true in a literal sense, it implies you think the only job for a tester is "to test". There is plenty that can be done before they start to test. For one, they can be meeting with the product owner and developers to fully understand the requirements. They can be busy working on a test plan, gathering test data, and so on. If they have the luxury of a good framework, they are able to start writing automated tests ahead of time.

at the end of the sprint there is typically nothing or very little left to develop/fix

I've yet to see a development team that has run out of things to fix. However, that's not what they should be doing at the end of the sprint. Towards the end of the sprint they should be helping the testers test the product. They can help write automated tests, they can code-review tests and fixtures/keywords/etc written by the testers. They can work with the documentation team to help them finish up their work, etc.

I've seen 2 approaches to handle this... 1) Let the team members decide what to do whenever they're out of tasks.

The flaw in your thinking is that individuals run out of tasks. Tasks belong to the team as a whole. They should not be doing other work as long as there are any stories or tasks left for the team in the current sprint.

Make room in the sprint only for development,

This approach is not within the traditional definition of scrum or agile. The whole point of agile is that an entire team is involved in working toward a common goal. That means that all work required to finish a story must be represented in a sprint -- design, development, testing, documentation, etc.

Finally, this is not the only other viable solution. You neglect the true solution, which is that every team member should pitch in as needed to help finish the stories in a sprint.

The goal is a team goal, but you're writing as if each individual person had individual goals ("finish my tasks"). If someone has nothing to do, they can see what is currently being worked on and offer to help. Or, they can take the next task or story and begin work on it.

  • 1
    +1. Agile processes require slack. In order to optimize a system, you often have to de-optimize subprocesses. In this case, you said it best with "optimizing the team." Anything else is a symptom of the utilization fallacy.
    – CodeGnome
    Mar 2, 2016 at 5:08
  • At my career start, I faced some companies expecting candidate to work on all PHP, Java, C#, Desktop Apps(VB), QA ( automated, manual ), Photoshop, CSS and so on. That time industry considered those companies to be less professional because of specialization value. I wonder if same pattern gain acceptance (even become necessity) under Agile. Mar 2, 2016 at 6:04

In all agile shops I've worked in, testers are considered chickens so they're not timeboxed in the sprint like the developers are. Prior to getting their hands on the software, testers should be writing plans and making sure the environments are set up properly to receive the software. As part of this they should be eyeballing any design documents such as they are.

Nextly, you should be looking to fill the sprint. There shouldn't be any spare time at the end of the sprint if the estimations are good although estimation of course is a black art so it rarely fills exactly.

If a developer does have spare time at the end of the sprint, this time should still be tracked to make sure it is adding value (learning a new framework, doing analysis, further testing etc).

Bug fixing is a perfectly acceptable activity to be put into a sprint. It contributes to a feature and so adds value. This should not be seen as time stolen from the next sprint - more properly finishing a feature.

  • 8
    Read the Scrum Guide. Perhaps you'll find the bit where it says it's okay to split the development team into testers and developers (hint, you won't). Mar 1, 2016 at 9:57
  • 3
    The document doesn't say you have development team members with specialisms, but you don't get to split a group off to treat like "chickens". Mar 1, 2016 at 10:14
  • 5
    To the down voters, what part of Agile training did you miss where it specifies that you should adopt a strategy that works for your team? Robbie Dee's team adopted what worked for them in their unique circumstances with their unique project and environmental constraints. Every company has environmental barriers and "damage" that need to be routed around. This seems like a perfectly acceptable approach to the question that was asked. The question wasn't about the best way to organize testers and testing efforts on your sprint team.
    – maple_shaft
    Mar 1, 2016 at 13:49
  • 4
    No. The OP specifically asked about Scrum. You can't do whatever you like and call it Scrum. It may or may not be agile, but having portions of your cross-functional "team" treated as external resources or as anything other than first-class members of the development team is not Scrum.
    – CodeGnome
    Mar 2, 2016 at 5:01
  • 2
    @CodeGnome is absolutely correct, and touches on a point I always bring up: Agile is a philosophy, Scrum is an implementation of that philosophy. The two are not the same thing, and abide by separate rules. (Yes, Scrum came first, but was later retrofitted to be an Agile implementation)
    – user22815
    Mar 2, 2016 at 6:23

In an ideal world, your team would be cross-functional. Everybody has their specialization, but everyone is able to work as another specialization as well. If your testers cannot code the most simple tasks, then you don't have a cross functional team.

The SCRUM way would be to enable your team to be cross functional. Your testers should have skills for test-automation anyway, it's a short step to coding some of the less complex things.

  • 6
    T-shaped people are one thing, having testers write code (unless we're talking for test automation) is quite another.
    – Robbie Dee
    Mar 1, 2016 at 9:35
  • 2
    This just assumes that only Testers have downtime in the sprint? Devs have downtime as well.
    – maple_shaft
    Mar 1, 2016 at 13:51
  • I assume that Devs can do testing without further training. Where I live that's part of the education and job.
    – nvoigt
    Mar 2, 2016 at 9:51

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