16

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?

Improve this question
8
  • 4
    Does this answer your question? what should I do when there is nothing to do in office
    – gnat
    Jan 15, 2021 at 16:09
  • 3
    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, 2021 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, 2021 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, 2021 at 9: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, 2021 at 12:21

7 Answers 7

Reset to default
47

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

  1. You're exceeding expectations and should be given more tickets, or more complex ones
  2. 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.

Improve this answer
6
  • 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, 2021 at 21:43
  • 4
    3. 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, 2021 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, 2021 at 9: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, 2021 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, 2021 at 15:27
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.

Improve this answer
4
  • 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, 2021 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, 2021 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, 2021 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, 2021 at 21:41
8

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.

Improve this answer
1
  • What is an ebb?
    – Koray Tugay
    Jan 16, 2021 at 17:48
4

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.

Improve this answer
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.

Improve this answer
4
  • 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, 2021 at 3: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, 2021 at 7: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, 2021 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, 2021 at 20:41
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.

Improve this answer
6
  • 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, 2021 at 9:50
  • 2
    Writing tests would be another example, though it would warrant the same reply as @Erik gives.
    – J.G.
    Jan 16, 2021 at 10:30
  • 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, 2021 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, 2021 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, 2021 at 19:17
-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.

Improve this answer
3
  • 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, 2021 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, 2021 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, 2021 at 15:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .