Being assigned bad/unwanted tasks if I finish my sprint early

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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!

Answer 5

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.

Answer 6

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

Answer 7

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.

Answer 8

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.

Answer 9

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.")

Answer 10

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.

Answer 11

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!

Answer 12

'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.

Answer 13

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

Answer 14

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.

Answer 15

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.