Recently due to team changes within the company, I have been put into a team that runs scrum. It was my first and I am not familiar with Scrum sprints and processes. Previously I work independently and reporting directly to my direct manager which is in a remote location.


Now, I am struggling between what's required of me versus what Scrum can do for me. I play a different role in the Scrum team because my work involves research and data analysis where I might be required to conduct a study which may or may not be related to the team's project. I feel a gap with other team members as the other developers are not familiar with research work and cannot take up my user story and vice versa. We just had our first official sprint run this week and I am having some doubts now.

  1. Is it possible to run scrum when we have people with 2 different roles working the same sprint but on different projects that are independent of each other? I have read about running 2 streams where one stream will be for research (in my case) and one will be for development like this article: Agile and User Experience: Two Streams
  2. How do I leverage from Scrum so that I can benefit from it instead of just going along with it because it's required of me?
  3. Poker Session - can we do away with poker session as I am trying to find a balance between the team velocity and my tasks. Is there a different way to evaluate my tasks so that it won't affect my team's velocity if I had to drop or create a new user story in the middle of the sprint.
  4. What is the main role of the Scrum Master when it comes decisions on matters regarding the sprint?
  5. Would it be professional to voice out my concerns that I feel that I need more researchers in the team and I need some flexibility from the traditional way scrum in other teams?

Edit: Is there a way to move this whole thread to Project Management so that it would be fair to those who answered this question.

  • 1
    It is going to be hard here to tell difference between what potential conflict are with Scrum process in general, and what are to do with problems with your workplace's implementation of Scrum. Definitely "job of the Scrum Master to decide all matters" is a big red warning flag if any of those decisions are about priorities, assignment, deciding what the estimates should be etc - but also Scrum can be run in a way where the impacts of inputs such as estimates and priorities are all logical, and you view Scrum Master as "running the show" when really they just implement the agreed system. – Neil Slater Mar 4 '16 at 8:08
  • 1
    I'm voting to close this question as off-topic because this is all Scrum-specific and would be better asked on the Project Management site (assuming it's on-topic there), not the Workplace. – Lilienthal Mar 4 '16 at 9:26
  • 5
    Scrum is a religion - a fundamentalist one. Wanting to tinker with the ceremony or admitting you're a non-believer will not go well. – TheMathemagician Mar 4 '16 at 14:08
  • 3
    @TheMathemagician I'd wager that Scrum haters have Scrum users beat when it comes to demagoguery. There are thousands of ways to use or abuse it in project management. Who are you to say that OP's Scrum Master wouldn't listen to a reasonable argument? – Lilienthal Mar 4 '16 at 16:28
  • 1
    @Cryssie Have a look at this site. Check in the chat first to see if your questions are on-topic. The problem with your post here is that the numbered list of question you have is only tangentially relevant to the interests of this site's userbase. The title of your question or a variation thereof is a better fit and I'd suggest you trim the rest out to focus on a single question like: "How do I make the case to my manager that I should be excluded from the Scrum methodology when it doesn't fit my work?" – Lilienthal Mar 4 '16 at 16:31

Scrum can be very useful, but it's a round peg in a world with a few square holes.

Scrum is great when there's a large amount of ongoing work, divided between roughly similar people, and when partitioning or prioritizing that work is difficult. Although that describes a good number of teams, it doesn't describe your work.

I have been on both sides of the fence in this exact situation, where scrum is being misapplied. It's usually obvious in a few sprints. Your legitimate gripes are being confused with the normal "this is useless", anti-process, anti-scrum blowback that is fairly common when teams start. So you'll have to let that phase pass on its own.

To argue your way out, I'd focus on the benefits to your team and management of the process, and how you're ahead on that. They key benefits are visibility, speed, flexibility and predictability. How do you propose addressing those? Why did you management choose scrum in the first place? Answer those questions and you can probably wriggle through getting your work pulled from the meetings.

On the flip side, you may still be useful in contributing to the conversation for everyone else's benefit, and the work that isn't yours. I imagine you have some skills that overlap, and you'll have a bit of an outsider perspective, while still being technical. That can be helpful for their sake, and would show good citizenship on your side. Continuing that a few weeks longer may help, and maybe then your managers will realize it is/isn't worth the investment of your time.

  • 1
    I'd say a great many square holes, not just a few. – jamesqf Mar 4 '16 at 19:14
  • 1
    Let me rephrase--"entirely made of square holes with varying amounts of roundness to them". – jimm101 Aug 9 '16 at 19:13

Scrum really isn't about your work, it's about the team's work. Its merits have little to do with whether or not the process works for your personally, and much more to do with whether or not the process helps teams within your organization work effectively. Which isn't a question that can be answered by looking at just one person's experience.


  1. Yes. At its most fundamental level a sprint is just a grouping mechanism for work. It doesn't violate the process if some of the work is on one project and some of it is on another. It may not be the most effective approach to have a team where different members work on completely unrelated projects, but at the same time it also tends to be ineffective to put too many people on the same project at the same time. So segregated workloads aren't uncommon, or even necessarily indicative of a problem.

  2. If it's being run correctly, Scrum should be a low-overhead process that gives you frequent (daily) opportunities to raise any issues you've encountered with other team members and/or management and get prompt assistance in removing any blockers from your path. You should get a passive benefit from the first aspect (less overhead means less time spent in meetings, and more time available to spend actually getting things done), and a more active benefit from the second (if/when you encounter blocking issues).

  3. Poker is one of those things that's about the team/organization. You don't do it because it helps with your work, you do it because it helps the team make an informed decision about how much work they can commit to in a sprint and because it helps the organization plan and understand when they might actually have a viable product to release. But look at it from the other side; if you don't participate and then the other team members underscope your work, the consequence of that is you being expected to complete an unreasonable amount of work next sprint. It's actually in your own best interest to participate in the poker sessions and to stand your ground if you think the rest of the team is underestimating your tasks. You're the team's only researcher, so if you don't participate they have no expert opinion to consult when scoping research tasks and will be less accurate as a result.

  4. It's the job of the Scrum Master to facilitate meetings, ensure blockers are removed, and to decide some aspects of the sprint (such as duration, etc.). They have fairly broad discretion, but not generally absolute say over "all matters". Things like prioritizing tasks in the backlog are typically the responsibility of the Product Owner, and scoping of tasks is typically the responsibility of the development team (through poker sessions), and so on. However every organization does Scrum slightly differently, and there can be good and bad Scrum Masters.

  5. By focusing on specific, solvable problems rather than blaming the process. Scrum isn't there solely for your benefit. It's there for the team and for the organization as a whole. If you present your feedback in a way that attacks the process because it doesn't do enough for you personally, the feedback is likely to be ignored. Scrum is intended to give individual team members a lot of flexibility, so if there's something specific that you feel is limiting your ability to be flexible that's probably a valid concern to raise. And if you feel you'd be more effective if you were on a team that included more researchers/data analyzers for you to directly collaborate with, that's also good feedback to give. Focus on specific, actionable issues like that instead of wholesale attacks on the process or vague desires such as having more "like-minded people" around.

Adjusting to a new process takes time, and it's not clear that you've really given Scrum a fair chance yet. Your previous process of only reporting to your direct manager, while potentially more convenient to you personally, is actually fairly inefficient from an organizational perspective. Nobody knows about what you're doing unless they hear it from your manager. That's a barrier to collaboration, is burdensome for your manager (especially if they have to do the same thing with every other employee they manage), and can lead to inefficiencies in terms of removing any blocking issues that you might encounter (because you're basically playing telephone with the person who can actually fix the issue, using your manager as an intermediary).

I'd suggest that Scrum does have strong benefits as compared to your previous process, even if you're not personally seeing them yet.

  • Thanks for your feedback. Just to clarify, I don't mean to have more like-minded people in the team but I was trying to say more researchers that understand the kind of work I do in the team but I stumbled for words. – Cryssie Mar 4 '16 at 3:18
  • 1
    Understood. Sounds like the real problem here is that you're on the wrong team. Unless you're there specifically to be a subject-matter expert for the developers, it would usually make more sense to put you on a team with at least some other researchers. – aroth Mar 4 '16 at 5:18
  • As they did not explain their previous process, I find that last statement rather presumptuous. – Weckar E. Dec 2 '18 at 10:12

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