Agile – Scrum – What are team members busy with during a sprint

agilescrumsprint

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?

Best Answer

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.
Related Topic