33

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?

holdenmcgrohen
  • 457
  • 4
  • 5
  • 9
    You seem to be falling for the [utilisation myth](https://hbr.org/2012/05/six-myths-of-product-development) – Nathan Cooper Mar 01 '16 at 09:59
  • @NathanCooper, not quite. My point is that lack of work can lead to demotivation for some people and to boredom/sloppiness for others. Of course, it's impossible and even harmful to try and keep people permanently busy. But if the project is short (no need for complex refactoring), the requirements are clear, and the code contains little errors, the amount of 'free' time a developer has during a sprint can be significant. – holdenmcgrohen Mar 01 '16 at 10:26
  • 1
    @holdenmcgrohen How are the estimates done - planning poker or something else? – Robbie Dee Mar 01 '16 at 11:13
  • @RobbieDee, regardless of the techniques, estimates are usually wrong at early stages of a project. And if the team tends to be extra-cautious, tasks are over-estimated, which leads to developers being unable to develop (there's nothing yet to refactor, the backlog tasks are not yet estimated or prioritized). – holdenmcgrohen Mar 01 '16 at 13:11
  • @holdenmcgrohen If you don't see value in creating good estimates for the sprint it isn't any surprise you have people kicking their heels at the end of sprints. Isn't any of this raised in the retrospectives? – Robbie Dee Mar 01 '16 at 13:17
  • @RobbieDee, I'm not saying I see no value in creating good estimates. I'm saying the chances of making accurate estimates for initial sprints of a new project are pretty low. – holdenmcgrohen Mar 01 '16 at 13:22
  • @holdenmcgrohen OK, point taken - and I agree. – Robbie Dee Mar 01 '16 at 13:42
  • 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. – Gort the Robot Mar 01 '16 at 14:48
  • Testers can learn how to code and coders and learn how to test, so you don't have this problem. – JeffO Mar 01 '16 at 21:42
  • 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 02 '16 at 02:01
  • 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. – user6005214 Mar 02 '16 at 00:34

4 Answers4

50

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.
Encaitar
  • 3,053
  • 19
  • 26
  • Yes, yes and yes. Spot on answer in every way. – David Arno Mar 01 '16 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 01 '16 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. – holdenmcgrohen Mar 01 '16 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 01 '16 at 12:53
  • @Encaitar Great stuff +1 – Robbie Dee Mar 01 '16 at 15:04
  • @holdenmcgrohen If they implement something not properly examined, maybe it doesn't get brought into the mainline until after it is properly examined. It might even be thrown out if it is found the developer picked the wrong task. – Cort Ammon Mar 01 '16 at 22:29
  • @Encaitar I agree, agile development works best with "**customer colaboration** over contract negotiation" (http://www.agilemanifesto.org/). If your developer aren't collaborating with their customer (you), and are instead treating SCRUM as a contract negotiation tool, it may be time for a retrospective. – Cort Ammon Mar 01 '16 at 22:30
20

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.

Bryan Oakley
  • 25,192
  • 5
  • 64
  • 89
  • 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 02 '16 at 05: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. – kuldeep.kamboj Mar 02 '16 at 06:04
1

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.

Robbie Dee
  • 9,717
  • 2
  • 23
  • 53
  • 8
    [Read the Scrum Guide](http://www.scrumguides.org/scrum-guide.html). 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). – Nathan Cooper Mar 01 '16 at 09:57
  • 1
    @NathanCooper Read my answer again - I said nothing about teams. Having T-shaped people absolutely doesn't mean everyone can do everything. You still need the mix of skills. Thinking you can take someone who has primarily been a tester with no scripting/unit test writing skills and suddenly have them knocking out quality code is fanciful. – Robbie Dee Mar 01 '16 at 10:07
  • "so they're not timeboxed in the sprint like the developers are" is about as far as I needed to get. So are testers not fully part of shipping every increment? Is their work not integral to your definition of done? TBH "testers should be writing plans and making sure the environments are set up properly to receive the software" are activities that sound like they advance the sprint goal, but you don't seem to frame them as such. – Nathan Cooper Mar 01 '16 at 10:13
  • 1
    That document also makes no mention of DBAs, build managers etc all of which are essential for delivery. Labelling everyone as a developer is helpful from a team perspective but you absolutely must have specialisation otherwise the wheels come off in fairly short order (as we found out when we lost our build manager). – Robbie Dee Mar 01 '16 at 10:13
  • 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". – Nathan Cooper Mar 01 '16 at 10:14
  • In a self organising team in a CI environment, the tester could be testing different things at different times - or even code from a previous sprint on an environment upstream of test (QA). That isn't to say they could never be time boxed - just that it generally isn't meaningful to do so. Also read the OP - the environment they're working in has developers and testers - even if your blue sky thinking doesn't. – Robbie Dee Mar 01 '16 at 10:20
  • 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 01 '16 at 13:49
  • *" you don't get to split a group off to treat like "chickens"* Absolutely you do - not everything can be accurately time boxed in advance. The build manager being a case in point. – Robbie Dee Mar 01 '16 at 14:24
  • 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 02 '16 at 05: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) –  Mar 02 '16 at 06:23
  • 1
    I actually agree with Scrum as a *philosophy* 100%. But back in the real world you have external software resources, legacy teams & shared resources. Scrum doesn't scale at an enterprise level. Period. You cannot possibly enforce all your touch points to adopt scrum from the bottom up. Of course it is ideal for a development team sat in a rented office in Berkshire writing product A as they're masters of their own destiny. And if you absolutely *do* have to term everyone as developers (p6) then how come I've never seen a job ad for *scrum developer*. Simple answer - people specialise. – Robbie Dee Mar 02 '16 at 09:01
  • 1
    And before you get all space cadetish and insist what is and isn't scrum then try working in a few scrum shops. I've yet to see any 2 the same. And to bring you back kicking and screaming to the crux of the point - the split between devs and testers isn't *my* distinction, it is the OPs... – Robbie Dee Mar 02 '16 at 09:05
  • 1
    lol @ agile shops. "Hello I would like two bottles of Agile please." "Certainly, sir." – Lightness Races in Orbit Apr 25 '16 at 21:10
-2

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.

nvoigt
  • 7,271
  • 3
  • 22
  • 26
  • 6
    [T-shaped](https://en.wikipedia.org/wiki/T-shaped_skills) people are one thing, having testers write code (unless we're talking for test automation) is quite another. – Robbie Dee Mar 01 '16 at 09:35
  • 2
    This just assumes that only Testers have downtime in the sprint? Devs have downtime as well. – maple_shaft Mar 01 '16 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 02 '16 at 09:51