Top ScrumMaster + Scrum Product Owner Questions from Training – FAQ

Scrum is easy to understand.

It can be the hardest thing to actually do.

Below are some of the most common questions we see in ScrumMaster and Scrum Product Owner courses.

FAQ on Most Common and Top Questions from ScrumMaster or Scrum Product Owner Training

How can Agile/Scrum be applied to Hardware or Solution projects?

Scrum Development doesn’t really work well in hardware development except in the aspects of hardware development that are done using software. Agile as a philosophy, though, works EVERYWHERE.

For example, the modeling and planning of the hardware can be done iteratively. The creation of simulation software (if applicable) can be done iteratively. Beyond this, however, much of hardware development is a task flow that must be followed and can be easily mapped out.

Scrum, however, can be used by people creating hardware. There’s still a Product Backlog. People can still commit to a certain amount of work in the Sprint. Daily Scrums can still be done to improve synchronization and communication.

Does Scrum conform to PMI standards? If so, how?

By definition, Scrum can’t confirm to PMI. PMI is a project management method. Scrum is a framework for managing people and workflow. It’s kinda like asking about the difference between apples and oranges. They’re just two different things. Not much else can be said.

What is a typical implementation of change from waterfall to Scrum?

1. Start with understanding your culture. Period.
2. Create a transition team to set vision, milestones, goals.
3. Pick a pilot project —OR — a piece of a larger project
4. Provide the proper training for the proper personnel
5. Run several Sprints — adjust as needed
6. Evaluate your results, adjust as needed
7. Move on to a larger group (e.g., another product development group) and repeat steps 3-6.

In Agile/Scrum, how do we deal with people working across multiple projects in parallel?

Well, pretty much the same as you do now. The detrimental impact to your projects before Agile/Scrum will still be there after. Working on projects in parallel is not an issue of development method. This is not a question of looking for the development method that WILL allow you to work on multiple projects at the same time. The answer we’re looking for is to find a way to work on one project at a time in such a way that all projects get done faster and with higher quality.

How many Scrum teams can a Scrum Master realistically run?

That has everything to do with the ScrumMaster, the teams, and the product. Experienced teams don’t need ScrumMasters as much. Experienced ScrumMasters can work with more teams efficiently. Difficult products can make both teams and ScrumMasters work harder to accomplish the same thing. In my experience, I’ve never seen a ScrumMaster work with more than three teams at one time (and not very successfully).

Driving efficient and simple solutions in Sprints – can Scrum design and work complex solutions effectively?

I frequently hear concern that Agile Development can handle complex problems because it doesn’t try to solve the entire thing up front before building it. The reality that I’ve experienced shows that complex problems cannot be solved in detail up front because there are too many variables and too many assumptions made about the complex problem when working out a solution. Thus, we end up spending a bunch of time up front to build a solution that ends up changing in large ways during the development effort. Agile Development, on the other hand, encourages looking at a complex problem at a high level and then solving the parts one at a time. Does this mean that Agile Development might make some mistakes in solution during the development effort? No. However, because you will spend so much less time up-front trying to create a solution, you will have some time during development to build a solution and even some time to make mistakes.

So, Agile Development solves complex problems “efficiently,” if not “effectively.”

Role of wikis or collaboration tools in Scrum?

Can be useful in allowing Scrum teams that are non-co-located to communicate. They don’t replace face-to-face communication, however, and should not be used as a complete replacement.

Where does Scrum track risks and major impediments?

Impediments are generally tracked, per Scrum, in the organizational or team impediment list. Beyond Scrum, project risks are generally handled in some form of project risk tracker or document. Backlog related risks are handled within each backlog item in the form of notes and other documentation and in larger story point estimates to account for the impact of the risk.

Does Scrum state that teams must use User Stories or are Use Cases acceptable as well?

Scrum does not make any assumption about the construction of a Product Backlog item (PBI). It can be anything from a task, to a feature, to a scenario, to a defect ID.

How to handle high priority fires/opportunities in the middle of a Sprint?

Per Scrum, high priority fires (defects) may pass directly into the Sprint. The team should address the defect and then determine the impact to their commitment to the Product Owner and adjust accordingly. Per Scrum, high priority opportunities either wait until the next Sprint or cause an injection of change so that a new Sprint can be planned around the high priority. In reality, teams and Product Owners will often remove a lower priority PBI in favor of a new, high priority PBI (the catch is to remember to solve and plan the new PBI — that’s why Scrum measures the change, to force the replan and conversation that must take place when (not if) change happens).

Are key decisions in Scrum tracked in non-functional requirements & stories?

That depends on the nature of the decision. Decisions that affect NFRs are frequently captured in PBIs or as a separate part of the DONEness definition.

When do you do functional testing, performance testing, volume testing, ADA testings, and deployments to test environments?

As often as possible. Daily if you can (which means that the testing needs to be automated). Deployments to test environments are completely dependent on your frequency of testing. Deferring testing creates technical debt.

At what point do you plan for the next Sprint since planning will take away team time from the current Sprint?

Yes, its true that planning takes time away from building, but we have to do it anyway, so NOT doing it isn’t the solution (nor is only having certain individuals do the planning — that just takes your developers out of the loop at a critical juncture). I use backlog grooming workshops scheduled for 60-90 minutes once or twice a week to allow the team to discuss what’s coming up in the next Sprint (and get it ready for solving). This allows the team to think about what’s next without being interrupted too often to do it. Teams that do this can accomplish more and more preparation in less and less time. Then, when Sprint Planning comes along, we spend the proper amount of time (1 day for a 4 week Sprint, 1/2 day for a 2 week Sprint) doing an effective job of planning because the PBIs are now nice and small and everyone understands much of the functional requirement of the PBI.

Any pointers to good books or websites about QA within Scrum?

Lisa Crispin, Brian Marick, Janet Gregory. Lisa and Janet have a good book out there called, Agile Testing: A Practical Guide for Testers and Agile Teams.

In your experience, what techniques have you used to recognize top performers? Is it recommended?

This is a loaded question at best. Scrum is all about teams and teamwork. Going out of your way to identify individuals could hurt those who are really trying, but aren’t the ones recognized. I think the question you have to ask yourself is, “why are you looking for top performers?” What is it you want to do? Do you want to recognize them for high performance? Yes? But why would you want to do that in an organization that is looking for high performing teams, not high performing individuals. See, the trap you can easily fall into is the setting of individual performance over that of your team. This is counter-productive. Individuals that have their eyes set on that particular trophy start setting their own agenda and worry less about their teammates.

If you want to recognize high performers, make it a peer-recognition. Let the team members identify that one person who really made it happen, but don’t get carried away with the award. Make it a lunch, honoring the individual. Something relatively small in cost.

The real awards should be based around high performing teams.

Should team members provide estimates on tasks they have no or limited expertise with?

They should be involved in the discussion, even if they can’t provide a realistic estimate.

What metrics are generally used to assess a ScrumMaster’s performance?

I can’t speak to “generally used,” but I can tell you how I would do it as a 23-year manager. When you are trying to evaluate an employee’s performance (not something I recommend getting carried away with — performance evaluation should be part of the normal coaching, not part of the compensation package), I look at it in terms of the roles that the individual plays. For example, a ScrumMaster can be described as:

1. ScrumMaster
2. Scrum Team Member
3. Software Engineer (or perhaps, Software Analyst, Systems Analyst, etc.)
4. Individual – career aspirations, goals
5. Employee

Now, what are this individual’s responsibilities with regard to each role?

1. ScrumMaster – e.g., Keep the team fully functional and productive. Did she do that? How does the team see it?
2. Scrum Team Member — e.g., Stay focused, get PBIs to DONE. Did she help with that? How? How does the team see it?
3. Software Engineer – e.g., learn new techniques, stay technically current, etc. Did she do that? How? How does the team see it?
4. Individual — e.g., is she trying to achieve a new role? Was there something specific she wanted to do this year? Did she do it? Was she effective?
5. Employee – e.g., did she follow company policies? Is she a contributing member of the organization? How? How does the organization see it?

If you do what most organizations do and claim this is linked to compensation, you will likely garner excessive disappointment when compensation and salary grades do not truly line up with the level of the performance offered by the employee. Instead, we need to keep our focus simply on being the best that we can be and profiting from the organization’s success in whatever way the organization can realistically afford to do so. The organization that skimps on sharing their success will end up with people who aren’t interested in success, just employment. The organization that shares their success with their employees ends up with people banging on their doors trying to get in. These are two separate issues and should be kept that way.

How to project a final product picture to customer if the project requirements keep changing?

The question answers itself. If the requirements keep changing, the final product picture will change as well. The best you can do is base your picture on what you know and change it as the product requirements change. If your customer is the one suggesting the changes, that should be enough.

If a team is running well with no obstacles, does the ScrumMaster run out of things to do?

Unlikely. Even with everything is beautiful for the team, there’s still the organizational impediment list that needs to be addressed. Beyond that, there’s the question, “Can my team’s performance be raised? How?”