During the current Sprint, my Team is doing mostly front-end tasks, I don't have any tasks, because I do back-end.

My Scrum Master says that I have to pick up tasks from another Team.

Question: Is that possible in Scrum?

I think we have awful business analysts that don't write adequate specifications. I think that is the reason why I am left without any tasks.

  • 1
    I'm not an initiate of scrum, not even a fan, but it seems to me that "self organizing team" is relevant here. Are you comfortable relaxing while your team members are striving to compensate for inadequate specifications? Isn't delivering the product more important than assigning responsibility?
    – MCW
    Commented Jul 26, 2018 at 10:37
  • @MarkC.Wallace they are mostly fixing front end bugs. There are no back-end bugs currently. So, they aren't working with specifications.
    – Wow
    Commented Jul 26, 2018 at 10:52
  • "inadequate specifications" includes "no specifications"; you're splitting hairs. How does that fulfill "Scrum replaces a programmed algorithmic approach with a heuristic one, with respect for people and self-organization to deal with unpredictability and solving complex problems. "??? I still think "self organizing team" should resolve the problem.
    – MCW
    Commented Jul 26, 2018 at 11:04
  • 2
    Does it matter whether or not it's normal? How does knowing that help you? This question seems be hiding an underlying question, about what you're trying to accomplish and how you think knowing about what is normal will help you get there.
    – Erik
    Commented Jul 26, 2018 at 13:09
  • 1
    I'm voting to close this question as off-topic because "Is this normal" seems to me to be a reskin of a polling question ("I'm having this problem. How many others have this problem too?"). As @Mark C. Wallace alludes to, there seems to be a legitimate underlying question here, but as it stands, this Question is off-topic.
    – Sarov
    Commented Jul 26, 2018 at 13:21

6 Answers 6


TLDR: Beware the 100% utilization fallacy.

I'm going to ignore your stated question ('is this normal?') and instead attempt to answer the underlying question.

Swarming is possible

As per the Scrum Guide:

Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.

As a corollary to this, as long as there is sufficient work for a Team, then there should be sufficient work for Team Members.

While it's not necessary for every Team member to be an expert in every functionality, a well-functioning Team should be sufficiently well-bonded, with enough opportunities for knowledge sharing, that swarming should at least be feasible for any given story.

Even if you know absolutely nothing of back-end development, you still should be able to swarm. You could, for example, sit alongside a back-end developer as s/he works, thereby increasing your cross-functional competency, which will help swarm more effectively in the future. Or, especially since your Team is working on bugs, you could spend your time as a QA - both confirming the found bugs are being fixed properly, and hammering at the product to find more.

Other value-adding activities are possible

Even if you don't want to work directly alongside your Team members, there are other activities you can perform to benefit the Team. You can do research or spikes to improve your own knowledge, and then disseminate it to the Team. You can go through the existing codebase and clean it up. You mention there being poor specifications - so perhaps you should work to improve them.

100% Utilization is a Fallacy

It seems to me that your Scrum Master is seeing you as idle as you have no tasks (or perhaps because you are idle, In which case, for the solution, see the section above).

However, the thinking that this is a problem is itself a fallacy. You need to work with your Scrum Master to clarify expectations. It's the Scrum Master's job to be a servant-leader to the Team, as well as to ensure that Scrum is being followed properly. Nowhere in there is the duty of making sure all Team members are being 100% utilized.

  • I didn't say that front-end and back-end devs are on different teams
    – Wow
    Commented Jul 26, 2018 at 13:47
  • That's the impression I got from your Question. I must have misinterpreted. So, what is the problem you're having, then? Is it that your Team is cross-functional, but you've run out of back-end work to do, so the Scrum Master s suggesting you do back-end work from a separate Team?
    – Sarov
    Commented Jul 26, 2018 at 13:51
  • Yes, exactly. She suggests I do work from another team's backlog. I am on the team that does product pages. And she suggests I do work for another team that does delivery/basket pages. I was wondering if that's normal in scrum. I am not even remotely familiar with their functionality. Like, they have already assigned story points to their tasks, I will not even make it in their story points, because I am not familiar with their functionality. Whatever they can do in 3 story points, I will do in 10 or more, for example.
    – Wow
    Commented Jul 26, 2018 at 14:43
  • @Wow Updated in response to clarification.
    – Sarov
    Commented Jul 26, 2018 at 15:43

Normal, probably not. Lots of folks have the "it's not my job" syndrome.

Personally I (as their Scrum Master) motivate our teams to get better at swarming:

Swarming: A behavior whereby team members with available capacity and appropriate skills collectively work (swarm) on an item to finish what has already been started before moving ahead to begin work on new items


If you do not have the appropriate skills you could pair with someone to start getting them, leading to T-shaped people.

T-shaped skills: A metaphor used to describe a person with deep vertical skills in a specialized area (such as UX design) as well as broad but not necessarily very deep skills in other relevant areas (such as testing and documentation). Team members with T-shaped skills better enable swarming behavior.


Swarming means keeping a low work in progress limit, preferable one or two. Helping other team members to get work really done (also known as DoneDone).

We have awful business analysts that don't write adequate specifications. That's why I am left without tasks..

Help him/her? Get some skills in writing specs and do the work together. Be proactive, instead of reactively saying it is their fault.

I think being an Software Engineer means that you can go from ideas to full-fledged solutions. This means breaking down an idea to smaller tasks that result into a working software product that is adaptable over time. This is your job, not?


This does not solve your question about doing work for other teams, but just how to help your own team finishing their work. Which I think should be your first priority.

My Scrum Master says that I will have to do the other Team's tasks.

I think the only good reason to work for other teams during a Sprint is if you can assist them with something they are stuck on. Helping them complete their goals, while not jeopardising your team's goals.

Picking up work from another teams Sprint backlog seems very uncommon, as you missed their planning session and context. Pulling in full stories into your Backlog seems acceptable if your team can work on it independently. You could start on it the next Sprint or when the current Sprint goal has been achieved earlier. The Scrum Master should not change your workload during the Sprint, only the Product Owner can renegotiate the scope with the team, according to the Scrum Guide.

Other things that come to mind are: Cost of context switching and Stages of group development. Working on a single area of a codebase and with a stable team is way more effective in the long run compared to switching teams and code of of other teams.

  • The scrum master is 90% analyst. She always just makes it seem as if she is working. She micromanages people and is a very unapproachable person whom everyone on the team dislikes. I don't want to help her. Because I will end up doing her job. She has been on our team for half a year and she doesn't understand functionality of our product whatsoever. She asked me why I have nothing to do as if she's my boss, when she doesn't do anything herself. She will usually use other people, like approach someone from the team, sit with them, and during daily say she was doing what that guy was doing.
    – Wow
    Commented Jul 26, 2018 at 14:53
  • @Wow How annoying for you. Personally I would try to get help from other areas of the organisation. Someone on a team everyone dislikes sounds like an impediment that should be handled by "Upper-Management" or HR (People Operations). I like how Martin Fowler puts it: "You can Change Your Organization or Change Your Organization." wiki.c2.com/?ChangeYourOrganization Commented Jul 26, 2018 at 15:29
  • I miss read your question, added an update for the working for other team parts. Commented Jul 26, 2018 at 15:43

I am hearing:

  • inadequate specifications
  • I-shaped (rather than T-shaped) people
  • working in silos (business analysts, front-end, back-end)
  • hand-offs (Waste)
  • Scrum Master telling Developers what to do (rather than self-organizing)
  • Developers working on tasks (rather than working as a team to deliver the Sprint Goal)

These are impediments. As a member of a self-organizing team, you have a responsibility to ensure the team makes them visible and works with the Scrum Master to resolve them.

I can't agree you have nothing to do.

  • Scrum master is only 10% scrum master, she is also the analyst, it is useless talking to her. She doesn't understand how scrum works and she doesn't to anything but micromanage people all day. During daily scrum meetings she makes up stories about what she did yesterday and what she will do today. But my question still stands. Is it okay that the scrum master is telling me to do other teams' tasks because I am free?
    – Wow
    Commented Jul 26, 2018 at 11:04
  • Even if telling me I should do other teams' tasks is a suggestion, is it ok to suggest such things?
    – Wow
    Commented Jul 26, 2018 at 11:11
  • @Wow: It is tempting to answer, "No" ...but maybe your Scrum Master has a 'higher purpose' reason for giving you this advice. I strongly suggest you talk to them about your concerns.
    – onedaywhen
    Commented Jul 26, 2018 at 12:50

From your question and your comments:

You are not doing Scrum. Your Scrum Master (arguably the most important role in Scrum) has not understood their job. They are there to protect the Scrum team. Scrum has no mechanism to protect a team from a bad Scrum Master. That your Product Owner is not keeping the backlog filled enough does not help either, but is of secondary importance as far as I'm concerned. If yours were a smoothly running Scrum team, you would simply jump in and help the analysts produce requirements when you are running out of those, but it seems that's not possible due to silo'ed analysts.

That said...

I would not worry so much about all of this. This happens all the time; Scrum is, in my experience, one of the most misunderstood aspects of modern IT. It's healthy on a personal level to accept this and not get too hung up about it. Yes, it is bad for the project and the company, but on the other hand plenty of projects like this survived just fine in the past, before there was Scrum or Agile around.

In your case, I would focus on your actual job of creating software, and start relaxing about the process. Sure, keep following the Scrum rules as far as you can, within the confines of your particular environment, but don't let a Scrum-gone-wrong (A.K.A. Zombie-Scrum, Scrum-But...) destroy your good mood.

Yes, sure, if your main "Scrum" team/project is not able to produce work for you, there is nothing keeping you from doing work from/for other teams. If this repeats, maybe you can naturally migrate into another, presumably better-working Scrum team in your company, over time.

Scrum aside, in any company, there is still one person who has the final say about what you do, and that's your direct boss. Put them into the picture with a small status email ("FYI, my main project didn't turn up tasks for me this sprint, I'll support team XYZ with their project for these two weeks - give me a head's up if you wish me to do something else") and then go find interesting IT work.

If you should have real downtime, sit down and optimize anything you can find. Be it something in your main project; researching a new framework; trying again to sit down with the requirements engineers to help them, etc.; or even just polishing up your CV...

  • I don't think "survived just fine" is a fair way to put it; the whole Agile movement began with the realization that the vast majority of IT projects went over-budget and over-deadline.
    – Erik
    Commented Jul 28, 2018 at 10:24

I think that picking up other work when otherwise idle has been a standard expected feature of just about EVERY job I have ever held, I mean why would you not?

Now I might take the view that the lack of spec is a problem, and iff I have any real task domain skills in the area where this product lives, I would probably take writing some spec and getting it signed off to be the most valuable thing I could do to remove the block on the backend work, but your team, your team dynamics....

Frontend/Backend is pretty much an artificial split at least during prototyping, and if you don't have a pretty good spec, you ARE prototyping.

The real question is, do you have good enough skills in whatever the frontend needs to actually contribute without being net negative work? I am a pretty good low level hard realtime guy, (Assembler, C, C++ on small cores and DSPs), but I know that if I tried to pick up some of our website stuff our web team would be cursing me, be sure of the reality of your skills before stepping outside your core competence.

I don't see anything particularly unique to Scrum methodologies here.


Consider asking to take this opportunity to swarm/pair with another teammate. This will give you insight into new areas and build the cross-functionality of your team.

Working outside of the team is (at best) an edge case scenario. It may be an OTO instance (sometimes crazy stuff happens) but asking you to work outside the team is not an agile practice.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.