What should I do when I have nothing to do at the end of a sprint?

Question

This is my first software development job. Initially I paired a lot with other developers but recently I’ve started doing smaller tickets on my own because I have just enough enough experience to complete them. I’m generally doing more than is expected of me.

Towards the end of each sprint the board has no more tickets to pick up. Other developers are finishing up their work so it’s not productive to join them a lot of the time but I want to be doing something or I feel stressed that I’m not actually working! This is 1-3 days away from the end of the sprint.

I can ask the lead dev to take specific tickets out of the backlog but those still have to be refined. If the answer is effectively no then I end up with nothing to do until the end of the sprint. I don’t want to be constantly bugging the lead dev because they are busy.

Everyone else seems to have things to do although some of the time people sit in calls of 3 where the third person isn’t doing much but they do learn from this.

I don’t want to give anyone a bad impression of me so I’m not sure what to say. I’m 90% sure that I could fix this with better communication but I don’t know what to do. What can I do?

Does this answer your question? what should I do when there is nothing to do in office — gnat, Jan 15 '21 at 16:09
Similar question on the Project Management site (from the PM rather than the developer perspective): What to do if a member of a team finishes all his sprint tasks ahead of schedule? — Bernhard Barker, Jan 15 '21 at 21:48
Everyone seems to be busy. - well, they always do. Are you sitting around staring into the air when finished or trying to look busy? — DonQuiKong, Jan 15 '21 at 22:14
Do you feel the team has a sense of shared ownership towards the sprint-goal, or is it more a "everyone fixes their tickets and if anything isn't done at the end of the sprint it's that persons fault"? — Erik, Jan 16 '21 at 09:51
"I can ask the lead dev to take specific tickets out of the backlog but those still have to be refined." -> can you suggest to change that towards doing the refinement a little earlier? Did you find out what others do when they are ready with their tasks? — puck, Jan 16 '21 at 12:21
@Erik the culture is good, definitely more of a shared ownership situation. I’ve never seen anyone be blamed for being “too slow” and if a ticket isn’t done at the end of the sprint, it just gets put in the next one. — Lucien, Jan 16 '21 at 15:41
@puck that’s a good idea, I’ll ask someone next time I pair! I think it’s a mix of personal development and joining other people but I guess I want reassurance that the way I’m using my spare time is fine, so maybe if I bring some of the solutions here to my manager they can confirm that they’re happy with it — Lucien, Jan 16 '21 at 15:44

score 47 · Answer 1 · 2021-01-15T21:47:38.623

47

Talk to your team lead - there's one of two things happening here:

You're exceeding expectations and should be given more tickets, or more complex ones
You're not doing enough work on the tickets that you're working on - should there be more analysis, unit testing, documentation that other members of the team are doing that takes up their time?

If you're doing ok according to your lead, then ask what more you can do to fill your time.

edited Jan 15 '21 at 21:47

answered Jan 15 '21 at 11:50

11

Great answer, it's probably important for the OP to first ask the supervisor if their work is up to par and if there have been any issues. If not, then bringing up that they need more work would be appropriate. Quite often, junior hires think they are doing much better than they are because of lack of diligence. – ldog Jan 15 '21 at 21:43
4
The requirement analysis is too way behind (there are cases a developer cannot push it forward). You have time to do some unit tests or settle the technical debt.

Nikolas Charalambidis

Jan 15 '21 at 22:18

If you add more work you will be in the scenario where you have work left over at the end of a sprint. Is that better? – user253751 Jan 16 '21 at 09:39

9

+1 for 2. I've frequently had juniors who were proud of finishing lots of work in very short time spans, but the work was done sloppily and bringing it up to par to meet our quality standards took a lot of time (either by reviewing it and throwing it back at the junior - multiple times - or by "giving up" and doing it ourselves because it was less work in the end). Make sure you are not one of them! A little bit of "gold plating" is OK if you're a junior who is supposed to learn. Just make sure you know what level of quality your team expects. – Heinzi Jan 16 '21 at 11:45

3

Yep that’s spot on @Heinzi, I’ve been told already not to assume that tickets in code review are done because they’re not and after going over my ticket in code review before anyone else looked I found something I missed out which would have taken up someone else’s time to point out and check again after I would have changed it – Lucien Jan 16 '21 at 15:27

@Lolums And sometimes, as my dad used to say, you have to shoot the engineer and ship the product. It would not be productive to spend the next 3 days going over old tickets in case you missed something. – corsiKa Jan 16 '21 at 18:13

score 16 · Answer 2 · answered Jan 15 '21 at 12:14

16

This is a fairly common question to occur. Generally look to see if there are any tasks you can do to try help complete the sprint goal. Examples

Help get tasks to done:

By doing QA for tasks (or helping out QA if you have them in the team)
Doing small PR suggestion fixes and tidy up (maybe ask first)
Acting on QA for someone elses taks (but ask them first!)

Help prepare for sprint planning/refinement by look through the backlog and

Ask questions on up coming tickets
Do data/info gathering if required
Maybe small proof of concepts to help speed up development of a solution (if using a new library have a look at how it could be used and create some demonstration code in a throw away branch)

In your retro or planning suggest having small tickets refined at the top of the backlog that could be picked up if this happens again next sprint.

answered Jan 15 '21 at 12:14

Webdevuk

1,224
1
6
9

10

I don't care how good the team is, no piece of software can have too much QA if the testing isn't delaying the release. I can always find work developing new tests or doing edge testing. I don't think I've ever worked on a piece of software still under active development with 100% code coverage for unit tests. – ColleenV Jan 15 '21 at 12:49
4

I love this answer but I think it could also mention self-learning. Was it a general technical knowledge, or getting to know better specific parts of the product being delivered (there's always these "only-Bob-knows" parts in any software...) – Laurent S. Jan 15 '21 at 13:11
1

Agree of the self learning, this could be reading through previous completed tasks and pull requests to get familiar with the code base and coding standards/review process of the team – Webdevuk Jan 15 '21 at 16:15
7

Also, documentation! I have never workd in a place where the documentation was perfect and didn't have any room for improvement. – Josh Jan 15 '21 at 21:41

score 8 · Answer 3 · answered Jan 15 '21 at 12:03

What can I do?

Talk to your boss. Discuss the ebb and flow of the sprints you have experienced. Then ask "What should I be doing when the board has no more tickets to pick up?"

Your boss might know of specific things you can do. Or your boss might tell you to speak with someone else (such as the project or team lead). Or your boss might suggest learning or other things you can do on your own.

If you passively sit on your hands when there aren't sufficient tasks to keep you busy, then you'll look like a slacker. If you actively ask for direction then you'll look like you want to get ahead.

score 4 · Answer 4 · answered Jan 16 '21 at 11:49

Education

Take the time to learn more about:

The domain (industry) you are in
The company you are working for
The system you are working on
The users of the system
Current issues and technical debt
Skills relevant to your position

The source for all this information can be:

Company website
Other departments and their publications
Ticketing systems you can query
Customer Service Tickets
Task tracking systems you can query (Jira, Trello, Pivotal, Azure, etc).
The backlog

Overall Result? Your increased knowledge can now help the company and its customers.

score 1 · Answer 5 · answered Jan 16 '21 at 00:40

1

This sprint/ticket based way of organizing project efforts is not ideal.
Project managers are not planning ahead enough and possibly wasting resources. Also leads don't have time to talk to the team? This does not sound good, hopefully it is a temporary situation.

If you do not want to bother teammates during a temporary busy period, I think you can use this time to study topics that will make you an even better worker and individual.

You might want to investigate how to improve the team's workflow or your own position, in a way that will make future situations always comfortable to you.
You can also go deep into technical topics that will be new skills for you.
You can take a glimpse at those future tickets and try to anticipate how they might be refined, and how to tackle them in each case.
You can also survey articles about the state of your industry.

answered Jan 16 '21 at 00:40

wip

207
1
6

2

"Project managers are not planning ahead enough and possibly wasting resources." Generally you don't want to plan for 100% resource utilization to give the team slack in case someone gets sick or a task takes longer than expected. – nick012000 Jan 16 '21 at 03:48
1

Good point nick012000. The fact that tickets for future sprint cannot be processed yet, still bothers me (it looks like a bottleneck that it would be good to remove). – wip Jan 16 '21 at 07:06
2

It's more that Scrum is not a good method for managing work. In a sensible process there would be a backlog of stuff to be done and new items would be added / refined / whatever when todo queue is short, not when calendar says so. – ojs Jan 16 '21 at 18:59
1

@ojs By the time you reach the end of the sprint, the Backlog should already be ready for the next sprint. So I wouldn't blame this on Scrum. – Llewellyn Jan 16 '21 at 20:41

score 1 · Answer 6 · answered Jan 16 '21 at 07:53

1

Documentation

That always gets shorted, and noone likes doing it. You can share your knowledge by writing up the notes while they're fresh in your head. That way the next person has a leg-up and can be effective sooner.

Don't assume that you'll remember how it all works after 6 months... We've all been there, or will be someday.

answered Jan 16 '21 at 07:53

Criggie

2,658
20
28

6

While this is a common thing that gets missed, "do it if you've got leftover time" isn't really a good fix. "Write the damn docs" should be one of the checklist items before a ticket is considered "done" in the first place. – Erik Jan 16 '21 at 09:50
2

Writing tests would be another example, though it would warrant the same reply as @Erik gives. – J.G. Jan 16 '21 at 10:30
@erik absolutely docs/tests should be a checklist item - did they get done? if so, are they done well? Will OP come back to this in 6 months and be grateful to themselves for useful notes, or did the checklist item consist of a single link to a now-vanished website? I've had that situation. – Criggie Jan 16 '21 at 10:47
1

I heavily prefer tests as living documentation. Otherwise a developer may come back in 6 months and say 'why are all these documents out of date and misleading with wrong information?'. – Michael Durrant Jan 16 '21 at 11:44
1

@MichaelDurrant Tests tell you what something's supposed to do, but not why. Both should be in place. If your documentation keeps getting out of date, then there is problem with a people not updating it when they make changes to the requirements of the project, and a further problem with no manager/reviewer enforcing this before the changes are merged. Fix those things, rather than giving up on documentation entirely. – Asteroids With Wings Jan 16 '21 at 18:57
1

@AsteroidsWithWings yes I agree. And at every place I've worked at, there is a problem with people updating it. After seeing this at 6 different workplaces I started to think that maybe it wasn't the people after all. I do know one guy that kept up the documentation really well at one place though. Unfortunately he created a ton and then left. Now the problem is even worse there. Management being passionate and even being able to update documentation has also been a rare in my experience. I've have seen it in some mature orgs but not much. – Michael Durrant Jan 16 '21 at 19:17

score -2 · Answer 7 · answered Jan 15 '21 at 12:57

-2

I think part of the problem might be this.

I can ask the lead dev to take specific tickets out of the backlog but those still have to be refined

Ideally tickets should be self-contained, they should be clear and contain all the information needed to work on them. This way developers can work independently on them without having to bug others for extra information/explanation.

If you are in a position to do so, I think you should press for better, more clearer tickets.

answered Jan 15 '21 at 12:57

thieupepijn

11,119
1
22
43

1

Tickets in the backlog often don't have enough information to enable working on them, because this information is only discovered during estimation and/or planning. I think this is what OP meant by "still have to be refined". I agree it's not a good idea to try to pull such tickets into the current sprint after it's started. – B. Ithica Jan 15 '21 at 16:01
I also think it's not a good idea to add new tickets to the next release when the sprint is already started. However you can work on those tickets and shelve them or put them in a temporary branch. And maybe it's fine that those tickets still need to be refined a bit. But it's better if the tickets in the backlog contain sufficient information. Because then, as I told in my answer, someone/anyone can start working on them without having to bother others. – thieupepijn Jan 15 '21 at 20:56
Tickets can be written by anyone who finds an issue although mostly it’s the product people who want to add features. But refining a ticket takes a long time compared to writing it because we want to find a good solution rather than just a solution- so of course most backlog tickets aren’t refined but there tend to be 1-3 that are. – Lucien Jan 16 '21 at 15:31

What should I do when I have nothing to do at the end of a sprint?

7 Answers7

Education

Documentation