I have been working in a Scrum team for more than 1 year. As this is my first job and have no previous experience so can't compare with anything else, so thought of asking here.

We have a basic Scrum team setup. Total 7 engineers, 5 developers, 1 QA and one designer. 3 developers are seniors with +4yr experience, and 2 I and another are juniors, 1yr experience.

We do sprint planning, estimate stories. But the seniors don't much work. We juniors do at least 60+% of the work in each sprint.

I have below problems, if any body can guide with them all.

  1. Seniors don't work but take all the credit.
  2. People outside of team don't know who worked on what, like management and other teams. So they think all work is done by seniors.
  3. They pick a story, and keep it with them for two whole weeks and just make them self look busy.
  4. Scrum master praises them in meetings, I don't know why.
  5. They have good communication skills, so they just communicate well and every body thinks they did all the work.

I want to know.

  1. Is this common in Scrum teams?
  2. What can I do in this scenario.
  3. If I raise a complain to Scrum Master, he will just say that Scrum is all about team, team works not individuals.
  4. Any guide you can give me if you have ever been in a situation like this.


  • 1
    if you use git, check the contributor graphs
    – Ewan
    Commented Nov 21, 2016 at 16:36
  • @Ewan we use mercurial/bitbucket, is there any tool for that. Other than awesome graphs, possibility offline. Thanks.
    – Blue
    Commented Nov 21, 2016 at 17:11

3 Answers 3


Parts of your question smack more of a workplace issue than a Project Management issue, but I'll answer what I can.

Is this common in Scrum teams?

Doesn't really have anything to do with Scrum. What you describe above, assuming the problem actually is as you describe (neither exaggerated nor misunderstood/misrepresented), is an issue with the workplace, not the methodology.

What can I do in this scenario.

Don't just bring it up to your ScrumMaster. Bring it up in the retrospective. This is an issue that affects the whole team, and thus should be visible to the entire team.

If I raise a complain(sic) to Scrum Master, he will just say that Scrum is all about team, team works not individuals.

This applies primarily outside the team. Within the team, the team itself still has to deal with intra-team issues. To take a hypothetical, extreme example, if someone in the team is slacking off, spouting off racist/offensive remarks, and throwing garbage everywhere, it's not like the problem can just be entirely ignored just because the other team-members are cleaning up after him/her. Yes, it can be considered a problem with the team itself. The team then has to deal with it.

Worthy of note is the fact that this is actually not even being followed, anyway, as noted by how you mention the senior members take/get all the credit. If Scrum is working properly (as your ScrumMaster claims it is), then the seniors do not get credit. The team gets credit.

Any guide you can give me if you have ever been in a situation like this.

Bring up in retrospective. If that doesn't work, first examine and research to make sure you have actually, accurately assessed the problem. If yes, then escalate. If that doesn't work, polish up your resumé.

  • Agreed with everything here, especially to bring this up in retrospective. Scrum tends to work when there is high visibility, accountability, communication, and trust. If you are accurate, you don't have any of those. Do you have 1 on 1s with a manager? If, as Sarov mentions, you are accurate in your assessment, and retro fails to change anything, that might be a good place to bring it up.
    – Majaii
    Commented Nov 18, 2016 at 17:10
  • Isn't this why points and velocity is used? If the team agrees a task has enough points for a weeks work, and they take 2 weeks to do it, it becomes pretty obvious that some people are underperforming.
    – Issel
    Commented Aug 18, 2021 at 13:31
  • @Issel Not necessarily. Maybe the task was underestimated, maybe the team got distracted by external factors, maybe someone scope creep'd the task during the Sprint (which shouldn't happen, but...), maybe a dev quit, maybe the task was unclear... Lots of possibilities. Hence, retrospective.
    – Sarov
    Commented Aug 18, 2021 at 14:25

As a Scrum Master I always like to promote swarming:

The idea is that you get all the developers to work (swarm) on a single story, instead of having each developer working on a separate story. The goal is to get more stories fully completed. It's better to have 80% of the features 100% done, instead of having 100% of the features 80% done.

Swarming works well with another Agile practice namely Pair Programming.

When using these two practices you optimize the team for knowledge sharing, focus and giving room for seniors to teach juniors. It will make it impossible for people to hijack the fun tasks, or in your situation 'fake' to work.

There are some challenges, most importantly you need to be able to cut up a story into work items that people can work in parallel on. My current team takes the following steps:

  • Hold a team-wide architecture and design session
  • The team starts thinking about a test-plan and come up with test-cases
  • They create sub-tasks on our Scrum-board
  • They pick up sub-tasks in rotating pairs

I would ask the Scrum Master or the team in a retrospective to try swarming or pair programming for a couple of Sprints. They are classic Agile practices, so it should be very acceptable. Certainly if you feel there are issues surrounding working as a team.

Other reads:


Sarov hits a lot of the main points here.

This isn't healthy Scrum. I've of course seen it all to often. As Sarov points out, the team needs to self-organize.

You have another channel to go with as well. That's your manager. If you're team isn't working and that's making you not happy, your manager should know about it. The manager's job is to make sure individuals have what they need to be most productive.

Here's an idea you could try and float: If you could either get yourselves another tester or be willing to take on your own testing you could suggest splitting the team into two teams. You're already at the upper edge of what is considered healthy and recent studies have found 4-5 person teams are more productive. Then put all the new guys on one team and all the old guys on another team.

My guess is the old guys are going to push back heavily. You most likely have a situation going on that I've blogged about in the past. It's a classic anti-pattern based on the Pareto principle.

  • Interesting article about the Pareto principle when viewed from an Agile perspective. Commented Nov 18, 2016 at 20:07

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.