A single user is mapped to a multiple teams in an organization which is handling multiple projects simultaneously. Can a scrum master assign the tasks to the user who is in multiple teams and multiple projects?


2 Answers 2


There are a number of issues with this approach:

  • Multi-tasking reduces efficiency. Every time they have to context switch between projects they will lose effectiveness.
  • Scrum is based on the idea of a known team capacity which is used to calculate the velocity. If team members change or are doing work for other teams then the velocity can no longer be accurately determined.
  • The person effectively becomes an external resource that needs to be coordinated. This will reduce the effectiveness of the team.
  • Many of the Scrum ceromonies are intended to be for full-time team members only. For example, the daily stand-up and retrospective are usually for full-time team members that are committed to the work.
  • The dual-team role forces there to be prioritisation between two independant backlogs. e.g. is it a priority for them to work on Story X for Team A or Story Y for Team B?
  • If I may add to your first point, some studies have shown the impact of context switching to be as much as 20% for each project over the first. Since it's often the company's top people that get split, this is a huge price to pay and it should be very openly discussed before deciding to do it.
    – Daniel
    Commented Jan 18, 2016 at 19:31
  • Also, it's a smell for a Scrum Master to be assigning tasks. The team is expected to be self-organizing in Scrum. The Scrum Master should work very hard to get away from the practice and coach the Developers to choose their own work. Commented Jan 19, 2016 at 20:58

We had a god-like developer working for multiple projects. He was a silver bullet for any issue. True savior in desperate situations. The solution here was to create custom filter in Jira for him to manage his workload as different projects used different flows and schemes. PM's managed issues priority collaboratively, with COO as an arbiter, using numeric prios from Jira Agile which are unique. He did not participated on Scrum meetings at all. Developer always worked on a top prio issues. His primary role was a firefighting (blockers issues on prod) and last resort(If we needed booster to close all issues from sprint backlog). We did not track his personal velocity as teams had different story points scale. All story points for issue's solved were added to a team velocity. That's how we keeped velocity more steady and mitigated unknown risks. One more thing about him is that despite his far superior hourly rate the average cost of a story point delivered by him was significantly lower compared to a teams he supported. So there were no negative impact on budget. I hope this war story was useful for you.

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.