From a technical standpoint, code metrics should be baked into your test-driven development (TDD) or acceptance testing, preferably in an a fully-automated way. However, from a Scrum perspective, the framework is not prescriptive. The correct framework perspective is that gathering and checking your current code quality metrics should be part of your Definition of Done. Reviewing the usefulness or accuracy of your metrics should be an ongoing part of your inspect-and-adapt cycle, which means: Any impediments related to metrics that are raised during the stand-up should trigger a review. Your current processes (including code quality metrics) should be reviewed during each Sprint Retrospective, provided that the issue fits within the time box and you don't have higher-priority process issues to discuss. At any time, work related to your code quality metrics can be added to the Product Backlog for prioritization by the Product Owner.

TL;DR I refuse to offer a personal opinion on the qualifications of individual instructors because we don't allow polling questions on PMSE. In addition, evaluating the cost/benefit of any particular class is out of scope for PMSE. However, the question about whether instructor qualifications matter for Scrum training seems valid and on-topic here. Define Your Educational Objectives Certification training has two goals: Get certified. Get educated. If you only care about #1, then it doesn't matter who the instructor is as long as you learn enough to pass the exam. On the other hand, if you want to learn things and get an education, then of course the experience, teaching skills, and background of the instructor will matter. Would you rather learn about space-time theory from Stephen Hawking, or from my cat "Mittens?" My assumption is that you'd learn more from a respected expert in the field, but it's up to you to assess whether any given instructor is sufficiently expert (and talented at teaching) for your educational needs.

I'd focus my answer on the levers that I can move, either easily or with some effort. The levers I cannot move, such as no product owner or the answer provided by the PM to the Steering Committee of a single iteration, are simply facts that create the environment in which you are working. Serves no purpose to ask questions about it or analyze it. It just is. The four iterations is a work estimate. It lives in some probabilistic distribution that can be as optimistic as one or as pessimistic as 10. Since it was not provided in this blurb, then my first course of action is to try to uncover where the four iterations live within the range. This drives the risk of the work from a time perspective and how I will track and report progress. Adding additional resources could help. It obviously depends on the resource elasticity of the work, which varies from job to job. To assume Brooks Law will always adversely affect you is simply wrong. That said, my next action would be to analyze the elasticity of the work and determine where I am in resourcing compared to where I think the point of diminishing returns is. Then, I will recommend staffing the project to that point. Then, I will determine if the BA's limited utilization on this project has any adverse effect. If not, then leave it. If so, then I would argue resetting his/her priorities such that (s)he becomes full- or near full-time on my gig. Once these levers are pulled, I would analyze the likelihood of my end date and report in a non emotional way where I will most likely finish. Pressure and potentially angry senior stakeholders notwithstanding, an answer well substantiated by thoughtful analysis is the answer. I would continue tracking, reporting variances and updated forecasts, in a non emotional and frequent way.

It is possible, but not recommended by most experts I know of, as these two have conflicting roles and responsibilities. PO is focusing on getting the most bang for the bucks, while the role of SM is to help the team get to and maintain its full potential in the long term. This includes shielding the team from external discruptions and ensuring they get only as much work as they can handle. So the PO is continually pushing the team to deliver more value, while the SM is pushing back to avoid overloading the team. If these two roles are being handled by the same person, one side usually wins over the other, resulting in imbalance. Mike Cohn explains this with a nice historical example in his blog. This question was also asked on Programmers.SE.

Individual rewards and incentives rarely work the way that was intended. Especially not in an agile team. As the old saw goes "Tell me how you'll measure me and I'll show you how I'll behave." As Spock would put it "The needs of the many outweigh the needs of the one." But perhaps more importantly, consider why you want to reward individuals and what you would reward them with. Mostly, we reward people to motivate them to do better. Turns out, financial incentives don't work for this. If you really want to motivate individuals and teams, appeal to their sense of autonomy, mastery and purpose. Have a read of "Drive" by Dan Pink. Fascinating read.

In a proper Scrum, it's definitely option 2. It's the team as a whole who decides about process changes. The Scrum Master is a servant-leader, not a command-and-control style leader. So even if she is convinced that a specific change in process is necessary, she shouldn't (and can't) force it to the team: she has to convince them, or preferably explain the situation, the problem(s) she sees and the available options to resolve it, then let them come to the decision themselves. That's one of the biggest challenges of being an SM, to keep one's mouth shut and instead just wait and listen to the team Note that even if the SM is perceived by the team to have the authority to make process changes by herself, if the team members don't fully accept such a change, it won't work; they will have buried resistance which may very well sabotage the process and eventually even break the team if not handled properly. Exceptions are always possible, of course So the above is not to say the SM can never, ever impose process decisions onto the team. I can imagine situations when e.g. the team is undecided for some reason (they are new to Scrum, and/or they are not accustomed to be a self-organising team so they need some hand-holding), so the SM has to make a decision on their behalf. However, she should still coach and support them towards becoming independent as soon as possible. Or if the proposed change is small and experimental, like "let's try the Boat Retrospective this time for a change". But by and large, these should be rare and limited exceptions rather than the norm.

In my experiences the one of disadvantages being a Scrum Master is when the organization (small to mid organization usually) not understanding enough SCRUM as a whole package, especially the new Scrum adapting organization, which mean there is still conventional project manager paradigms that organization expect from a Scrum Master.

I would take great care diving straight into being a Scrum Master, as you risk being perceived very negatively by teams. I am a Scrum Master who has come from a development background, which makes it much easier to fit in with the team naturally and not come across as 'management'. There are three stages of Scrum Teams, sometimes referred to using Shu-Ha-Ri; a martial arts term. Your background will mean you fit into teams in some of these states much easier than others. In the 'Shu' (Obey) stage teams are learning the fundamentals. This requires more of an enforcement attitude from the Scrum Master, and is where technical knowledge would be most useful. This is where teams are likely to be creating their 'development best practice' - so to me the scrum master should be enforcing code reviews, helping to implement XP or whatever approach the organisation are taking, and suggesting (often technical) additions to the definition of done. This is where many 'Scrum Consultants' (who are often not technical) seem to be failing the industry to me - they bring in 2 week sprints, self organised teams, and backlogs, but do not address the most important part - the underlying development standards that Scrum was built and relies on. Most teams never leave this stage, and this is where Scrum Masters who are not technical are really hurting the industry. The next stage teams reach is 'Ha' (Digress) where they are working as a good Scrum team, and start to understand why they are doing things, rather than just following the process. This is where the team have the basics down and are working as a good team already. At this point they must have good development practices in place, so a Scrum Master who is less technical could probably get by. The team is motivated to keep up their technical excellence, so the Scrum Master doesn't need to be driving this, but might want to keep reminding the team to keep up their technical excellence. There is still a risk development practices could slip and the team not notice, and without being technical a scrum master may never know. If you get the rare chance to work with a team at 'Ri' (separate) who is hyper-productive, I don't think you need to be technical. This is probably the best sort of team fitted to your situation. Your psychology background would probably make you better than most Scrum Masters at really getting to the bottom of deep, hidden issues that many Scrum Masters might miss, so you may want to try to specialise in working with awesome teams that are trying to etch out additional improvement. This is where teams are coming up with their own ways of working, maybe abandoning Scrum all together. I have a software development background, and have led multiple organisations through the Shu and arguably Ha stages - often after agile consultants have already done a lot of damage by bringing in Scrum without any consideration of the development practices it relies on. If you are involved in agile adoptions, ensure to work with a development manager or senior developer to put best practice in place BEFORE bringing in agile. Without this, non technical Scrum Masters can seriously break teams and organisations. You can do it, but the more technical knowledge you can get the better.

Summary This previous PMSE answer clearly summarizes why there is an inherent conflict in having a Development Team Member perform double-duty as Scrum Master: The Scrum Master role is a process referee role. This is inherently a conflict of interest with the Team Member role. For the same reason that you have (theoretically) impartial referees in professional sports, the Scrum Master role should be separate from developer roles. — CodeGnome, PMSE Answer Scrum Master and Development Team Member are Separate Roles The Scrum Master is defined as a separate role within the framework by The Scrum Guide: The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. — The Scrum Guide, Schwaber & Sutherland, p. 5 While a separate role doesn't always require a separate person, effective Scrum practice requires that this triumvirate should have a clear separation of duties in order for the framework to operate as designed. The Scrum Master is also has a full page of unique responsibilities within the framework. See The Scrum Guide (Schwaber & Sutherland, pp. 5-6) for the complete list, as it's too long to simply and copy and paste here. In short, while the framework doesn't forbid a team member from also wearing the Scrum Master hat, it is extremely unlikely that a full-time developer will have the bandwidth to be an effective Scrum Master (or vice-versa). Part of a Scrum Master's job is to manage Scrum artifacts and provide an interface to the broader organization; such tasks limit the capacity of a single person to provide service delivery as members of the Development Team, and will create a more or less permanent drag on the team's potential velocity. In my considered opinion, this unnecessary drag is itself a conflict of interest. Responsibility vs. Authority Any organization that doesn't value the Scrum Master role sufficiently to create a proper separation of duties is unlikely to understand the inherent conflict of interest between service delivery and process refereeing. This means that the Scrum Master's job of removing process impediments and enabling organizational change may be limited by politics and org charts. Any time a position has responsibility without sufficient organizational power or delegated authority to carry out those responsibilities creates a situation ripe for failure. Even if one disregards the inherent conflict of interest in the roles, the consequences to the project in disregarding the separation of duties may be dire. Perhaps your organization will understand that you will have less time to develop when wearing the Scrum Master hat in addition to your other responsibilities. Perhaps they are also enlightened enough to see you as more than just another member of a service delivery team, and will actively engage with you on essential business process re-engineering issues. Perhaps and perhaps...but I have never personally seen this work out well for a project, or the dual-hat wearing person stuck in the middle. Your mileage may vary. However, I wouldn't bet my career on it.

I used to take pictures as well. Another possibility is having some (or many) take notes in a shared google doc. This also work for on-line retrospectives. The key point, in my opinion, are any action points. It's all nice and fine to dig down to root causes, but in many cases it's quite unproductive: many root causes lay outside of the scope of the project team and there's little if nothing that can be done to address them adequately. What are important are: the issues ("start doing", "stop doing", "continue doing") any actions to be taken, with somebody responsible for them This does sound like "team-themed" stories, so I think documenting them as stories, can also be appropriate.

This question seems to be from two mis-understandings about Scrum. I don't really see how it follows that Scrum Masters cause a reduction in quality by keeping focus on the definition of done. The Scrum Master does not write the definition of done, the team does. The Scrum Master helps the team enforce the standards of quality that the team has decided upon. The quote from Clean Code does not apply. Most managers might obsess about schedules, but Scrum Masters do not. They work with a different variable, they keep the scheduled fixed and instead adjust the scope of the project. A Scrum Master will drop user stories to keep the deadline the same. However, that being said, I think that Scrum takes an overly simplistic view to team structure. You need to build your teams with the right balance of experience and skills so that they can self-organise. Ideally, when a team has a gap, they can recognise it and ask for more support in that area. You can't just put random people together and hope for the best. Edit: As Jmort253 mentions, you have also assumed that a Scrum Master is non technical. This doesn't have to be the true, but in any case Scrum Master should limit the amount of directing and decision making that they do and instead make sure that they facilitate the team to make [technical] decisions.

TL;DR Is it or can it be a Scrum Master's responsibility to: setup/improve a code review software system? setup/improve the continuous integration process? provide scripts/macros/helper tools to make the development process easier/more efficient ? No, no, and no. These responsibilities rest with the self-organizing development team. If you turn the Scrum Master into a DevOps engineer, that person will no longer be able to focus on the core responsibilities of the Scrum Master role. The Scrum Master Role The Scrum Master is the shepherd and evangelist of the Scrum process. In other words, the SM acts as a process referee, and "removing impediments" generally refers to working with the team, management, and the stakeholders to raise the visibility of process-impeding issues and providing a constructive framework for all parties to cooperatively develop an organizationally-appropriate solution. The Team's Responsibilities If a Sprint Retrospective identifies code review as a process issue, then the Scrum Master should capture that issue and provide guidance to the team and the Product Owner on how the framework allows them to improve that part of the process. This may include: changing the "definition of done" to incorporate code review processes, the Product Owner adding a new user story to Product Backlog that prioritizes the installation and configuration of a code review system, or anything else that everyone agrees fixes the issue for the team and the project. The same is true for continuous integration and tool chains. Whether driven by technical debt or a desire to continuously improve the process, the Sprint Retrospective is the place to raise such issues. Ultimately, it is the Product Owner's responsibility to prioritize the work related to process improvement (by manipulating the Product Backlog), and the team's responsibility to implement a solution once that work has been prioritized by the PO. The Scrum Master's job is just to make sure that the Scrum framework is properly leveraged to give everyone involved the process tools that they need to do these things within the context of Scrum. If you take your Scrum Master off-task by assigning implementation work, then that person is no longer fully-dedicated to performing the tasks that are essential to the Scrum Master role. Don't do that. Intra-team process and technical implementation are responsibilities that rest within the self-organizing development team. Neither the Scrum Master nor the Product Owner should be sticking their thumbs in those particular pies.

Introduction Division of stories into smaller stories should be done by the Product Owner. Scrum Master and developers can help in that, especially during backlog refinement (grooming). Division of stories into tasks (meaning: technical tasks) is only the responsibility of the development team – this is about HOW the stories will be implemented. So I believe, neither Scrum Master, PO nor you (if you are not a dev) should not divide stories to (technical) tasks. I just answered a question about „who?” and not „when?”, but that was for clarification. Now answers to your questions: Answers a) The answer to „When?” is, in my opinion: during sprint planning. I think, no other formal meeting is intended for that in Scrum. Also whenever someone sees that a task may be added to the story, he may add it. But formally, HOW the stories will be implemented is discussed among developers during Sprint Planning meeting. b) Ask the Scrum Master to stop talking ;), to stop entering stuff to JIRA during the planning meeting. He should facilitate the meeting and encourage developers to do this work and not do this instead of them. Give pens and postit stickers with story names to developers and let them write on a sticker the tasks for that story. And take the keyboard from Scrum Master. He does not need it during the meeting. Give it to someone else. Think about empowerment, about encouraging for self-organization of the dev team. They will not start to do this job if SM is doing it for them. Some „space” needs to be created. Make them feel responsible for technical solutions, for dividing stories into tasks. c) SM should support PO before the planning in creating and splitting user stories and making them better understandable. Does he do that? UPDATE regarding a): The tasks like: design, tests, review should be a part of general Definition of Done of the team. I do not think it is needed to put them to the story during planning. It depends on what is the goal of adding them there - to have them visualized so that the size of the story can be estimated well or just to have a checklist if all the steps were done. If it is needed for estimation and the team prefers to have it written down, then it is fine. If the team do wants to have those tasks in JIRA to have kind of checklist (do they want? or you want it? :)) then a developer when starting to work on a story can add those generic tasks. During planning it would be enough to mention it - that's something that SM can do: "guys remember that you need unit tests as well". In my team tasks added to a story during planning session are more like: add a new button to screen A, create a new screen B, create a new db table, improve the SQL query. We put "unit tests" tasks usually when we know that in a specific story we expect a lot of effort in making/maintaining unit tests. Usually we do not write down "unit tests" task to a story as we all know it needs to be done.

TL;DR [I think] the only way to truly understand the benefits [of agile] is to become a certified Scrum Master. Is this a good idea? No. Agile practices encompass a spectrum of practices and frameworks well beyond Scrum, so a Scrum Master certification won't necessarily impart agility in a broader sense. In addition, doing more of something you dislike is not setting yourself up for success. Instead, you should look for roles in organizations or job sectors that use a framework more to your taste. You can even make desirable project management methodologies part of your job search or interviewing criteria. How is Scrum Mastering Like Teaching? If you hate math, should you become a math teacher? Probably not. You won't enjoy your time spent learning the subject. Even if you eventually master the material, you'll probably have a hard time inspiring anyone else to learn about a subject that you intrinsically dislike. In some ways, being a Scrum Master is quite similar to being a teacher. You are not only the shepherd of the Scrum framework for the organization, but you are also often called upon to: educate teams in the methodology, dispense Solomon-like wisdom based on your experience with the framework, and be an evangelist for the framework and its practices. Those things are hard to do if you actively dislike the very framework you're responsible for promoting. That will not set you (or your team) up for success with Scrum or any other agile framework. Instinctual Drift and ScrumBut In addition, if you lack passion for the framework or disagree with its underlying principles, you are going to struggle with finding solutions to process problems that don't violate core principles. Instinctual drift will lead you into grafting non-agile patterns onto your process, leading to a perniciously-persistent ScrumBut environment that will (over time) look more and more like whatever framework you do feel comfortable with. Recommendations Learn More About Agile Frameworks If you want to learn more about agile frameworks, by all means take a class or workshop to learn more about them. Take your pick from any agile topic that interests you, including: Scrum Kanban Lean Extreme Programming Cynefin Find Roles Based on Your Preferred Framework Despite what you may believe, non-agile frameworks are still quite prevalent in the field of project management. Whether as a developer or a project manager, you can certainly search out roles that use more traditional frameworks. In fact, if you go that route I would encourage you to ask employers about their project management methodology during interviews. Find out if they do big up-front design, or ask whether they use detailed specifications instead of user stories. Whatever it is you dislike about agile methodologies, figure out what your preferred approach is and seek out positions that value that approach. For example: Hate pair programming or cross-functional teams? Find individual-contributor roles. Hate user stories? Find roles that are based on up-front specifications. Hate incremental planning or iterative development? Find organizations that use waterfall development or traditional project scheduling approaches. Whatever it is you want, it's out there somewhere. Unless you're a serf, vote with your feet and work within an industry or organization that uses project management practices more to your liking.

TL;DR I told the developer to stop working on anything not prioritized by the Product Owner regardless whether own time or not. From a framework point of view, this is likely to be the correct approach. It's certainly what I would recommend as an organizational statement of policy. It reinforces Scrum processes and practices (e.g. time-boxing), and reduces risks to the organization, the team, and the developer himself. However, from a psychological point of view, the correct team-management answer is less clear. A person's personality and drives, as well as his individual requirements for remaining tightly engaged in a project, need to be balanced in terms of the overall benefits to both him and the project as a whole. What follows is an examination of some of the benefits and risks associated with allowing off-the-clock work. It is certainly not exhaustive, but should provide a solid starting point for your own risk/reward analysis. Your mileage will definitely vary. Benefits There are a few potential benefits to letting the developer work on something he's passionate about in his own free time. These may include: Supporting his passions. Many knowledge workers value personal achievement, pride in their work, and the approbation of their peers at least as much as they value a paycheck. Supporting these values can be good for individual and team morale. Personal growth. Encouraging developers to grow as programmers by expanding their knowledge of programming techniques solving problems they find interesting may lead to improved code quality and new insights for the team. Doing this outside working hours costs the company nothing, financially. Individual investment. Someone who feels passionately enough about a service or product to work on it on his own time is likely to be more engaged than someone who just wants to show up every day and collect a paycheck. Product quality. People who are passionate about their work may be inspired during through their off-hours activities, whether or not those activities are directly related to the project. The project can certainly benefit from such inspiration, and (barring any risks as detailed below) such contributions may improve the overall value or quality of the team's product. In short, caring about one's work or about a project that consumes close to 40% of one's waking life is generally a Good Thing. On its face, there would seem to be few reasons to discourage this, but the potential upsides should be carefully balanced against the potential downsides for all involved. Risks to the Team The risk to the team is that it may encourage the organization to think about non-billable hours as available for their estimates. Scrum is specifically about setting a sustainable pace within time-boxed iterations, so work that occurs outside the time-box skews the metrics and sets unsustainable expectations for the team. In addition, it risks confusion about some core agile principles such as: Time-boxing. Something is either done or not-done within a time-box, and you don't want to set the precedent that time-boxes can be disregarded. YAGNI. If the feature isn't part of the current Sprint, and isn't important enough to the project to be a priority on the Product Backlog, then it isn't important enough to expend resources on. Even if it's just the developer's personal resources, working on YAGNI items sets a bad precedent for the team. It may also reduce respect for the Product Owner's essential role in setting project priorities. Risks to the Organization While unlikely to be a significant legal problem with the one-sided, work-for-hire contracts most IT workers sign these days, it's still a bad precedent to accept unpaid, private work into a commercial code base that isn't under an open-source license. You might want to consult your legal department about this, but it just seems like a Bad Idea to me. Risks to the Developer The developer himself runs a few risks here. In particular: He risks developing bad habits related to time-boxing and sustainable cadence. He risks a poor work/life balance that makes sustainable pacing at work more difficult. He risks losing sight of the collective ownership of the code by thinking of portions of the code as "his." He risks identifying with the code quality of his contributions, rather than with the ability of the team to deliver value within a time-box.

There isn't much of difference in recognition/acceptability of both certifications. One big difference is that to get Scrum.org Professional Scrum Master I you don't have to go to the training. They offer trainings, but they're optional. You only need to pass online exam and you can even try out your knowledge for free in online assessment. Despite requirement of getting 85% on PSM I exam, it's very simple and most of the questions are obvious. For scrumalliance.org Certified Scrum Master, their training is mandatory and for many years training was all it took to get certification. That's right: no exam. So, the value of certification was next to nothing. Now it changed and you need to pass exam. I'm holding both of these and attended both what I would recommend: if you're looking to get certification, go with Scrum.org PSM I - you won't have to invest money in training. If you want to get to Scrum training, I would focus not on ScrumAlliance vs Scrum.org, but rather on specific trainer. Unfortunately both organizations have great and bad trainers and before investing money into Scrum training I would suggest asking someone for opinion on specific trainer.

In traditional Scrum, all of these roles are considered part of the same scrum team. Release backlog items get moved into the sprint backlog when committed to by the entire team (no matter what function the individual team members have) and then tasked out (again, by the entire team). The reason scrum doesn't usually separate out the functional areas of the team are 1) just because you're QA doesn't mean you don't have something to contribute to developer discussions and 2) you're all working on the same product and should have some view/input on the product as a whole so you can catch any conflicts between functional areas. Your front-end developers need to know what your back-end developers are doing and vice-verse, as an example. Where the functional areas really come into play are when team members are pulling items from your 'Not Started' lane of your card wall. If I'm a QA guy, I'm going to pull tasks to work on that are QA specific first. If I'm a front-end developer, I'm going to pull tasks to work on that are related to the user interface. It's up to the individual team member to work on items related to their functional area. The question that always comes next is - What if there aren't any tasks for my functional area left? The answer is - give something else a try. If nobody's working on it, it won't hurt for you to give it a go. Not only will that give you insight into how the other functional areas work, but also how your product works in areas you might not regularly see. You can always hand the task over to someone from that functional area later (when they're available) and you'll have learned something from the experience. That's traditional scrum, which is how the question was phrased. If you're looking for advice specific to your scenario, that's a whole different discussion and will get into the reasons you're doing things the way you are.

Who Owns Impediments The Scrum Master should not be "taking ownership" of impediments. The role of the Scrum Master is to facilitate communications and referee the process; the whole Scrum team is responsible for addressing impediments. Tracking Impediments as Sprint Backlog Items With that said, impediments that can be solved with a hallway meeting or a phone conversation probably don't need to be tracked. However, if the impediment is significant enough to generate an in-sprint task, you should definitely create a user story and place it on the Sprint Backlog. Note that in-sprint user stories shouldn't add story points to the sprint, since they should generally be dependent stories of some other Sprint/Product Backlog item. However, if an impediment outgrows its parent story, either in level-of-effort or scope, then it needs to be escalated to the Product Owner to see if: the user story can be added to the Product Backlog for a future sprint; the user story that triggered the impediment can be refactored or removed without compromising the current Sprint Goal; or the current sprint can be terminated early, followed immediately by a Sprint Retrospective and a return to Sprint Planning.

Roles and Responsibilities for Team Composition This is an interesting question, because it addresses some of the subtleties of self-organization with agile frameworks. In particular, it highlights the differences between authority and influence. Scrum Team Members are responsible for identifying impediments (e.g. the team doesn't have sufficient expertise in database design) and recommending adaptive improvements (e.g. suggesting that John Doe the DBA could provide the experience the team lacks). Team Members are also responsible for exerting influence on team composition by making recommendations about adding or removing people from the team. Product Owners are (often) responsible for resource budgeting. In such cases, the Product Owner would be responsible for approving or declining resources that would be charged against his budget. This falls squarely into the core Product Owner responsibility of setting project priorities. Scrum Masters are responsible for facilitating discussions about project resources (including resource constraints), process impediments, and recommendations for process improvement. However, Scrum Masters generally lack authority to directly implement organizational change. When the Scrum team agrees on an approach, the Scrum Master is responsible for ensuring that the team's recommendations reach the appropriate decision-makers, and for promoting the team's interests within the larger organization through influence. Applicability to Your Case Unless the Scrum Master has been assigned additional authority beyond the typical scope of the role, he should not be making hiring or resource-allocation decisions unilaterally. Doing so is not a generally-accepted Scrum practice, and is certainly not in the interests of team-building; nevertheless, it occasionally happens in certain types of organizations. You are quite right to bring up your concerns and recommendations within the team, but it is the Scrum Team's joint responsibility to agree on a solution and a spokesperson. However, deciding what people or resources the team needs, and how the team could best assist the Scrum Master in representing the team's interests to the rest of the organization, is most definitely not within your authority to handle alone. Organizational authority, whether on behalf of the company or the Scrum team, must always be delegated. The Scrum Master would be quite right to flag a team member taking a unilateral approach to this issue as outside the framework's generally-accepted practices.

This a requirement, and therefore the Product Owner shall figure it out by contacting the target company. While waiting for the answer, the team can start thinking about a solution which is kind of browser independent, or can get some data about the most popular browser in the domain and start working on it. These last two ideas are not approved by the Scrum framework, because according to it, the team shouldn't do anything which hasn't been approved by the Product Owner or the customer, in order to avoid waste creation.