Scrum - What are team members busy with during a sprint

Question

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.

Cons:

• 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)

Cons:

• 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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.