I am a software engineer in a startup, and we work in two-week sprints.

We sprint plan every two weeks and we get assigned tasks, and sometimes I will finish all my work before the next sprint.

The problem is there's a backlog of tasks that no one really wants to work on, i.e. maintaining legacy code, front-end changes, etc. The other engineers don't tend to finish their sprints before the next load of work is assigned, so I'm usually left to work on the bad/unwanted tasks.

The problem is, I feel as though I'm being punished for doing well at my job, and I'm not sure how to bring this to my managers attention.

I've tried the following:

  • Assigning more work to myself in the spring planning meetings, but sometimes these are the only tasks left over.
  • Assigning these tasks to other engineers. The problem with this is that they don't get around to doing them over their other tasks.
  • 95
    "my sprint", "get assigned tasks". This sounds rather dysfunctional to me. In a well-functioning scrum or agile team, the sprint is for the entire team, not individuals, and you don't get "assigned" tasks, you pick them up when you're done with a previous task, maybe even collaborate with other team members on a single task. And if you have nothing to do, then you should help other members of your team to complete the sprint goal. – Mark Rotteveel Mar 4 at 11:52
  • 1
    Is it explicit policy that you’re supposed to work on these tasks if you finish early, or is that just something you’ve taken upon yourself? – Kaz Mar 4 at 16:38
  • 19
    Aren't those task at the top of the prioritized backlog? In which case, aren't they going to be assigned to everyone in the next spring anyway? Otherwise, it means those are not high priority, so why would anyone want you to waste your time on it? – njzk2 Mar 4 at 18:23
  • 1
    You've just got a nice reputation for working better than your peers, so what you might try is to use your reputation to pick better tasks at next sprint with a bit of overload comparing to your peers. And as you get more good tasks, your peers will leave with more backlog boring job to do. But while you do better job, the will have to deal with it. – fixerlt Mar 6 at 18:49
  • 1
    Use it as an opportunity to shine even more. Think about how appreciative everyone will be when you say you've fixed that one annoying issue no one has wanted to touch. You'll also be surprised about the obscure parts of the tools and tech you use that you'll learn about when debugging and fixing hard issues. – lukeic Mar 6 at 23:49

15 Answers 15


You aren't being "punished" - as a general rule these less desirable tasks aren't dreamt up by the business to punish people, they genuinely need doing. A task is no less necessary or important because it's not appealing.

i'm not sure how to bring this to my managers attention

You don't - right now you probably look like a rockstar, you're not only getting your tasks done, you're doing it faster than your peers and helping the business clear down things that probably would end up falling by the wayside. If you go complaining about the situation to your manager you'll just look like a prima donna or even childish.

  • 23
    Don't complain about it highlight it. Not only are you looking good, you should make it a point to mention to your manager all the extra bugs you are fixing (make sure it is in his status report). Then when pay reviews come around make sure to remind him. Yes it is "shit work" somebody has to do it and your manager should recognize the person that is doing it. – Martin York Mar 4 at 22:00
  • 29
    I can see both sides of this debate. On the one hand it's good to know where your passion lies. On the other hand every job (even the "cool ones") is comprised of 99% "ughh" work and 1% "yay!" work. Trying to avoid the 99% isn't going to work out well long-term career-wise, as motosubatsu points out here. And there is value in learning to do a wide variety of things, and especially to do things no one else wants to do (and thus probably isn't good at). You'll be much more valuable to your employer if you demonstrate a wide berth of skills and a willingness to roll up your sleeves. – bob Mar 4 at 22:34
  • 24
    And I don't think motosubatsu was being rude. They didn't say OP was a prima donna/childish (at least as I read the answer), they said it would make them look like a prima donna/childish, which honestly is a real possibility. You don't want to get labeled as someone who's unwilling to ever do tasks you don't like. – bob Mar 4 at 22:37
  • 22
    @bharal I can only presume you've never worked for anyone. Sometimes the work isn't exactly what you would like, but it's important to the business, and it has to get done if you're also going to get the bits that you do enjoy. If you refuse to do things which aren't your exact favourite thing to do, you're not only a prima donna, you're very soon going to be an unemployed prima donna. – Graham Mar 5 at 8:48
  • 6
    At one end of the scale is prima donna, at the other is doormat. – Dave Gremlin Mar 5 at 16:53

The blunt answer is there will always be unglamorous work nobody fancies doing. The problem is: it needs to be done and somebody will have to do it eventually. You have the necessary skills and the time. You are paid by your employer to work a set number of hours a week - so, if you have capacity and are asked to complete some of that work there isn't a lot you can do - short of looking for another job.

In practical terms I'd look to approach it as follows:

  • You're using scrum so there is presumably a prioritised backlog being maintained somewhere.
  • Agree that a certain amount of time - say 30% - will be set aside each sprint to deal with legacy issues, tech debt, refactoring, front end changes etc.
  • Interleave these tasks with the more strategic/roadmap type work in the backlog. If you say 30%, then 3 in every 10 backlog tickets should be this type of work.
  • Groom them and pull them into sprint as normal. In this way you can ensure everybody does their fair share of grunt work.

Alternatively, if you can't get buy in for that approach, you can cherry pick the tasks you want to do since their absence from the main backlog suggests they can be done in any order, whenever time allows. Maybe you could even look at the next big ticket that will require investigation or spiking and make a start on that instead.

As an aside: if you are frequently left with a sizable amount of extra capacity towards the end of a sprint, you might want to look at your planning sessions. It would seem to suggest you can wring more out of each sprint and boost velocity.

  • 14
    Maybe read my full answer - I've suggested an approach OP could take. At the end of the day however, he who pays the piper calls the tune. The same person most likely decides what tasks are important and which are rubbish. I guess it's possible "bharal off the internet said not to do them" might work - but if I was OP I'd be reluctant to risk it. – amcdermott Mar 4 at 14:55
  • 8
    you know the tasks aren't important because they're not assigned. nobody reallt cares if they're done or not, so doing them is a waste of time. – bharal Mar 4 at 16:25
  • 5
    @bharal it's easier than that: either the tasks are at the top of the prioritized backlog, or they are not. If they are, do them, if they are not, don't. If you don't agree with the way the backlog is prioritized, that's a different question – njzk2 Mar 4 at 18:25
  • 13
    @bharal maybe we have a different definition of backlog: anything that's not in the current sprint is in the backlog. It's prioritzed so that the team knows what to groom for the next sprint, and what they'll work on next. – njzk2 Mar 4 at 19:32
  • 11
    @bharal You really and truly don't understand. It's nice to be able to show off new features, sure. But any technical ability is entirely destroyed by refusal to do anything other than what you want. If you refuse to do work which is still important for the company, then you will initially be disciplined and eventually fired. No company will employ you on that basis - and you will start to find it hard to get work at other companies too, because you won't get good references. This is not the way to have a career. – Graham Mar 5 at 8:56

I'd suggest starting by talking to your manager or scrum master. The fact that your co-workers can get tasks assigned, not finish them and then just throw them to someone else is not good. If the tasks are prioritized correctly, The maintenance they "didn't get around to" should be a higher priority on their task list for the next week. Eventually that maintenance task they are avoiding is priority one and they'll have to start explaining why they are skipping high priority tasks.

Another approach, one we use at my company, is to have one day a week as a maintenance and bug day. That way everyone has an assigned amount of time to work on those tasks that most of us tend to avoid.

Lastly if this remains a problem I'd suggest explaining how you feel about this to your manager and try to get them to fix this issue. However this doesn't always work out too well and once you're at this point. A lead or two on a new Job, or at the very least a brushed up CV is important to have.

  • 4
    If talking to your manager about this leads to you getting fired, either you have a terrible manager, or you didn't approach the conversation with the proper care and nuance required. – NotThatGuy Mar 5 at 0:34
  • @NotThatGuy, Bob didn't say that he'd get fired, just to have a relevant resume/CV available. That could mean the OP leaves the job for something better or more interesting on their own. – computercarguy Mar 5 at 21:21
  • @computercarguy That's how I interpreted it, and how many other people might interpret it too. Regardless of how they meant it, getting fired is a possible risk: there are indeed some terrible managers out there, as well as some people who are exceptionally good at sabotaging themselves by saying the wrong things. If they meant there aren't really any options remaining after that, except for moving jobs (or even if they didn't mean that), I would suggest more explicitly saying that. – NotThatGuy Mar 5 at 21:54

I have been in a position similar to you, where I was fast enough at the primary tasks that I ended up with the boring stuff for the most part. It sucks, but it is part of the job.

If this is a regular occurrence, though, what I would consider is talking to your manager about it. Not complaining, and not asking to get out of it, but just talking to them. "Hey, I notice I get done faster than anyone else, and it means I get all the junk nobody else wants to do. I want to help, but I'd also like to grow my career. Is there a way I can be helpful and productive while also advancing my skills?"

Part of your manager's job is to keep you happy, especially if you are a top performer, and it's entirely reasonable to talk to them. Just do so in a constructive way, one where you are either asking for ideas of giving your own while still being positive about doing the boring stuff.

One specific suggestion I would have would be to see if you can specifically get some time to learn a new skill - say, ask if you can schedule X number of hours for developing a particular new skill that is useful to the company in your time after the sprint is finished. That both helps you out AND makes you look good!

  • Talking to the manager is a good idea, but they may think that refactoring old code or doing other "crap tasks" can be a way to "advance you skills". They may try to convince the OP that streamlining the Db, simplifying complex code, removing unnecessary legacy code, etc. are all ways to "advance skills" that other employers like. It's somewhat true, but it's also a way to become a doormat when there's only one person doing this and no one else has to bother with these tasks. I've been in the silo of "fix all legacy mistakes" before, and it's not fun. – computercarguy Mar 5 at 21:25
  • @computercarguy For sure - and it can be a good way! I had many conversations with my managers over the years (mostly just two managers for the bulk of my time, and both good at managing, fortunately!) which went along the lines of "this is how you get to point B - by doing this work". But they might be able to either reframe it in a way that's useful to you, or often are able to find a little training/self-improvement time, especially if you are able to show tangible results from it! – Joe Mar 5 at 21:58
  • Sure, if you have a good manager, which is unfortunately too often not the case. Trying to get time for self-improvement on company time is often like pulling teeth from a chicken. Even when I was in a dept that allowed it, we had to log it and I was questioned why I "always had time" to do that in a sprint, instead of doing more work. It being a double-edged sword is a problem, too. Unfortunately, I've had more negative experiences than positive when it comes to workload, which is why it seems like I'm "always being negative". I'd love for these things to work out, but know they often don't. – computercarguy Mar 5 at 22:07

Keep in mind, it's the people who excel at scut work who are usually trusted with the most interesting work. You can come to enjoy it, as a way to unwind between more challenging assignments.

If you finish your assignments early, you aren't going to be allowed to just sit around twiddling your thumbs. If you want to have something more interesting, you need to be ready with a suggestion. You can score some great projects that way.

That being said, I do think it's a problem if these unwanted tasks are piling up. I would address it that way, rather than complaining that I'm the only one doing them. You can bring it up in a retrospective.


Being assigned bad/unwanted tasks that no one else wants if i finish my sprint early, so feel like I'm being punished

Welcome to software engineering.

Unfortunately this is very common and within these teams, developers usually learn it is better to procrastinate or pretend they are still working on a sprint until the deadline. If they finish early, they are essentially punished with undesirable jobs that others are avoiding by pretending to be busy!

If there was adequate compensation for finishing sprints early and taking on back log tasks then it wouldn't be seen as a punishment however, it often goes unrecognized. - Partly because it's not proof that you are performing well. Maybe your sprints were easier etc...

Essentially this is all down to inexperienced management of a tech team. I don't want to suggest your manager is inexperienced, but I question why this situation has been allowed to happen and why there isn't a processes in place so the undesirable work is distributed evenly.

An attempt to explain this may be misunderstood as whinging. Instead of trying to explain it, I would suggest offering a solution to it instead.

Here are a few possible things you can do.

  • Continue to finish your sprints early and take on the backlog tasks everyone else avoids, keep a log of how many you get through. Use this to ask for a raise or promotion by showing your manager you're outperforming your colleagues. - it's not guaranteed.

  • Finish your sprints but don't submit the task, wait until the deadline. Use the time to learn new things for yourself.

  • Talk to the manager and come up with a procedure that covers how backlog tasks are handed out between sprints. Eg. When a developer finishes a sprint, they must complete 3 backlog tasks before they move on to their next sprint/project etc..


The other answers are good, but I'm going to take a slightly different tack. If you are regularly working on tasks that haven't been prioritised into sprints, then you are working on the wrong things.

The idea of working on the backlog if you complete your sprint early, is meant to be an exceptional case, that you resolve, not something that keeps happening.

There are various reasons why it can happen.

  1. You are consistently underestimating what can get done in a sprint. This can happen if you have developers of varying ability, as it sounds you have. In this case, it sounds like when you finish tasks, it may be better to help the other devs achieve their sprint tasks through things like pairing. This will also help level them up, so that they are more productive and this problem will go away.

  2. Your tasks are too large and although you can happily commit to one or two tasks in a sprint, but not the extra task, so you consistently have free-time left. This suggests you need to have smaller, more granular tasks, so you can commit to one one of these smaller prioritised tasks.

  3. These backlog tasks are actually important to the business and they are relying on someone, currently you, to do them. But if you start estimating the prioritised tasks more accurately, then they will stop being done. The answer to this is for them to be properly prioritised and included in sprints and, assuming developers pick up tasks by priority and not what they want to do, then they will be spread more fairly amongst the team.

  • 2
    Matt, my slightly-dissenting "take" on this is that there are probably quite a few tasks – legacy code, user interface, etcetera – that are not being dealt with right now in the "development sprint" cycle. Perhaps because folks don't see it as "development" ... who knows. Now, maybe this is something that management and/or the sprint team does need to address, because it's not-quite-right to let such tasks repeatedly land on the shoulders of one person, no matter how willing(?) s/he might be or how "good at it" s/he is. The OP might do well to discuss this privately with management. – Mike Robinson Mar 5 at 0:55
  • I agree (I was trying to make that point, but obviously failed :-)) . It seems to me these tasks aren't being properly prioritised because developers don't like them and maybe management don't realise how important they are, and this gets concealed because they get picked up and dealt with by the OP. – matt freake Mar 5 at 8:49

When you're running out of assigned work in the sprint, ask your manager what they want you to do. They're the one who should be prioritizing work for you to do. If you're regularly running out of work to do, then you're being underutilized.

If this extra work you've been finding isn't included in the sprint, the reason they're not being worked on is because the management feels that they aren't as important as the assigned work.


Yeah ... like others have already said ... "shaddup, you are a rock star!"

This (koff, koff ...) "legacy code" is what still runs the business, and those "front-end changes" are what highly-visible users highly-visibly see and use.

And you(!) are the one who can be relied-upon to get that done. Your co-workers haven't figured out the business importance of that. (Hint: "Don't tell 'em.")

  • 3
    The OP is only a "rock-star" if they get the appropriate recognition for it. If they get siloed into it, like I've been, and the new features are given to others, that's not a healthy place to be. I mean, the guy that unclogs the toilet is a "rock star" for making the stink go away, but he's probably still covered in feces and making minimum wage. – computercarguy Mar 5 at 21:37
  • While the answer is probably well-intended, it suggests to consolidate individual differences among the team members instead of – what I think would be best – making dealing with the legacy code a collective team effort. – Theo Tiger Mar 8 at 20:24

When we ran our own shop we went about it like this:

  • We put the undesirable tasks into the sprint if they really needed doing.
  • We took on a load of work that would satisfy and impress clients.
  • We estimated fairly but aggressively.
  • When everybody was done with everything (no fudging the definition of done, swarming on tasks to help people who are behind), we took the rest of the time in the sprint off (often one or one and a half day).

Suffice it to say that this can be extremely motivating when done well.


Perhaps offer an alternative.

Hey boss, I find X interesting and worthwhile to work on because <how it benefits the project>. If I get my goals done early this week, can I work on that next, while I wait for our next meeting?

It's a positive way of offering a solution that benefits everyone.

If accumulation of technical debt ever becomes a problem, your team lead can figure out how to deal with it when that happens. That is part of their job, after all. If it does end up becoming a problem, maybe you could even bring it up and suggest a team-based solution!


'Front line' and 'Rear echelon' are completely different mind-sets. (The twit who shouted 'grow up' needs to understand this.) So it's not a question of vanity when 'rock star code cutter' doesn't want to slog through housekeeping and bug fixing and intake of breath documentation. Conquering new territory and consolidating the gains need different approaches. There are all sorts of ways to manage this problem, but square-pegs in round-holes isn't going to be helpful.

It's a management issue. My suggestion to management would be: If there's a bunch of housekeeping then make it a proper project with a settled routine rather than suddenly switch from deep-coding to bug-swatting. Then find the right person to do it.


How do you distribute tasks within the sprint?

In theory, the team fills the sprint with tasks from the backlog, informed by the priority ranking of the the user stories and (if you have them) the priority ranking of the tech stories. Within the sprint, each team member (or perhaps several team members together) starts a story, works on it, and finishes it. The team is responsible for the sprint result, and no one developer owns any one unstarted story. They're all in a sprint owned by the team.

In practice, not all team members have the same skills and knowledge. The team as a group will have a pretty good idea on who should be doing what to maximize the team performance. But when it is no longer a team working on a common sprint goal, but individual team members doing their parallel "sprints," the scrum process needs improvement. On the long run, this solo work will harm the team. Just imagine what happens when one team member has a vacation, or gets sick.

So there are a couple of steps to improve the scrum culture and process:

  • Make sure that stories are cut small enough to be finished by 1-2 developers in 1-2 working days (less the usual scrum meetings).
  • Make sure that stories are described well enough that most developers could work on them if they had to. Not every developer, realistically, but more than just one or two.
  • Make sure that the finished story is documented well enough that another developer could start the next story. Documentation is not a goal in itself, but it is a valuable part of having maintainable software.
  • Make sure to stop starting, start finishing when there are stories in progress. If a story gets blocked by dependencies, don't keep it in progress, push it back. There is the concept of a WIP limit (work-in-progress limit, set in relation to the team size).
  • Any developer is free to start any unstarted story. This bullet point is going to make the real change if the first four have been implemented.

Whenever you are done with an "urgent" user story, you pull another "urgent" user story. Until all the "urgent" user stories are finished. Then you and all other devs can use the rest of the sprint for "necessary scutwork."

Of course your colleagues might wonder if you have ulterior motives if you suddenly start harping on the scrum process. But doing so will help the product and the professional skills of each developer.

  • Do you have a culture of merge requests? Where I work, at least one other developer has to read, understand, and approve every single line of code that goes into the main branch. (If you don't use branches and merge requests, that needs to be fixed much more urgently.) Merge requests are also a kind of scutwork, but they're necessary to finish any story, so our team gives them priority.
    In addition to code quality, merge requests also improve the "bus factor" of the team.
  • If you have merge requests, are you doing them right? They are not about seniors checking the code of juniors, and rewriting it. They're about getting a common understanding of the code and the definition of done. It is easy to get defensive when someone else does a critique of the new code, but if they have objections you better have an answer -- and if your answer is valid, they should be professional enough to accept that.
  • Are you doing pair or swarm programming? Especially for difficult sections of code, that can actually save man-hours if you get things right the first time ...

This is harsh, but:

You need to grow up.

These tasks are not "bad", they are necessary but you simply don't want to do them. That's fine, except someone has to do them eventually, and you're part of a team. A team succeeds or fails together, and if those necessary tasks don't get done because everyone on the team selfishly acts like children and says "I'm not doing that because I don't want to", then the team fails.

Now if you're the only one who ends up doing these tasks, then you do have cause for complaining, because being on a team also means everyone should be sharing the good and bad things equally. If this is the case, you need to bring it up with your manager ASAP, because it indicates that your other team members aren't pulling their weight. It may also point to your team members taking on too much work; ideally every developer should have some slack time at the end of a sprint, exactly for handling these "backburner" tasks. (If you have no time left, you're either really good at planning or, more likely, you've overcommitted.)

You also need to reevaluate your assumption that refactoring legacy code is a negative thing. Failure to address technical debt is the number one killer of software products and teams, and the fact that you're actually getting time budgeted to address it is great. Refactoring old code is a great way to learn about aspects of the system you aren't familiar with, which leads to a better overall understanding of the system as a whole, which makes you a better developer.

In fact, if you are currently the only one handling these tasks, there's an opportunity for you to carve out a niche for yourself in the team as the guy who cleans up after everyone else. Being a "code janitor" may not sound glamorous, but if you're good at it your codebase will be healthier, your team will be more efficient, and together you'll all get more work delivered. Just make sure that your efforts are acknowledged - e.g. in sprint planning, "oh yes, this task involves subsystem which I reworked last sprint, so I estimate it will be story points less as a result" - because if you're a good janitor, it's often easy to vanish into the background.


Well, you've told us what you don't want. You don't want to work on rubbish tasks. But What do you want?

Work out how you want to spend your time at the company - managing ppl, working in new features for business, or just working in the code you like, and propose that.

You only get what you ask for in life, and if your don't push for it you end up doing what someone else wants. Some ppl like that - no problem, that's a life choice, but you have leadership spark in you, so you need to foster that.

And that means pushing for what you want. If you don't have the self confidence, then repeat out loud to yourself that you are enough, that you radiate self confidence etc.

But you're competent, push for what you want. if this company won't oblige, find one that will.

  • 8
    I know enough people with that attitude. Yes, it works at the beginning. Maybe you will get one or even two promotions. At some point people will notice that you have no endurance and can't solve real challenges, instead you're only picking the fun tasks. If you want to do this long term you have to switch companies frequently or start your own business. – Chris Mar 4 at 22:27
  • 1
    @chris what area you talking about? what does endurance have to do with pushing for what you want? what is it about being a yes man that implies you can solve problems? the only people I want to work for my are those solving business problems, and those who have ideas. i outsource non critical work. – bharal Mar 4 at 22:41
  • Who said that those tasks are not solving a business problem? – Chris Mar 5 at 17:55
  • 1
    @Chris, if the tasks are continually skipped over and not put into a sprint, but are continually at the top of the backlog to pretend they are important only when someone finishes their work early, then they aren't really important. I've worked at a place like that, where the next sprint had "new" tasks that skipped the same tasks skipped the last 6+ sprints, but those "new" tasks were in the backlog last sprint, if not longer, too. And being a self-advocate is a very important aspect of mental health and not being siloed into a bad job you hate. – computercarguy Mar 5 at 21:50
  • 2
    @computerguy & bharal Because Product Owners are notoriously bad at handling technical debt, that is why the developers are responsible to push for those tasks. OP is the only one doing it in his team. See pm.stackexchange.com/q/14345 for advice. Besides that I never said that prioritization isn't necessary. You're distracting from the fact that this answer is based on unfounded assumptions that 1. those tasks are useless 2. avoiding hard tasks is helping your career. – Chris Mar 6 at 10:23

You must log in to answer this question.

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