Get certified - Transform your world of work today


Finding Strong Scrum Resources in a Less than Standardized World

1 December 2015

Kathy Loveless
AIM Consulting



More and more companies are turning to Agile to improve their project success rates, and Scrum is the most popular method. The problem is that as you transition your company to a Scrum environment, it is a challenge to find candidates with a legitimate Scrum background. Due to the flexibility of Scrum and the eagerness of many to obtain Scrum experience, many people are not actually qualified to work within a Scrum team, especially in transitioning environments.

That might sound a bit negative, but I've seen a lot of Scrum team candidates in my time. After interviewing a Scrum business analyst candidate who claimed five years of experience yet who couldn't tell me what a "story" was, I've become skeptical. So how do you find the right people who are going to move your company forward?

Test the terminology

The easiest and most basic way to determine how much experience a candidate has is to have them feed you some of the terminologies. I spent a good 15 minutes with the aforementioned business analyst asking her, in multiple ways, "How are business requirements captured in a Scrum environment?" Ask questions that force the candidate to give you the terminology. They may give you different answers, like calling the timeboxed development a sprint or an iteration, but both show knowledge.

Here are some other sample questions that should work for any team member:
  • What are some of the artifacts in the Scrum process? (Answer: sprint backlog, product backlog)
  • How is team progress measured? (Answer: velocity)
  • How are increments of work sized? (Answer: story points or T-shirt sizing)
If they're using the terminology, make sure they're using it correctly. I once had a résumé come across my desk that said the ScrumMaster candidate managed the "burnout chart." (The correct term is burn-down chart.) Although I have been on teams where burnout was an issue and a chart mapping it might have been a useful tool, the Scrum-prescribed burn-down chart is more effective.

A candidate with experience should have no problem with this test. If they do, they haven't worked in Scrum. You really don't need any more evidence before moving on to the next candidate.

Ask about how their team works

If your candidate has passed the first step, it's time to drill down a bit deeper. The next step is to determine whether your candidate really knows how to work in a Scrum environment. The tricky thing here is that many times the candidate doesn't realize they haven't worked in a real Scrum environment.

With so many companies wanting to say they're Agile, you'll find there are many different flavors of Scrum being used today. It's good that companies and teams are able to adapt the Scrum process to their environments, but many times these adaptations have nothing to do with Scrum. Sometimes they are more of a Waterfall adaptation than a Scrum adaptation.

To determine whether the candidate is right for your company, you'll want to understand how the candidate's current environment works. Many companies say they're doing Agile, but they're really just doing some kind of iterative development. As a development team, they're soft-planning a time increment with no product owner, no artifacts, and no demos. All the team has done is added a time increment to their delivery without any of the other processes.

For companies looking for development resources, this is a real caution. Hiring a developer for a Scrum team who has been working in a Scrum environment that is less strict is almost the same as hiring someone with no experience. When Scrum processes are placed on these types of employees, they'll have to adjust to the transparency and reporting that will be required. If all other factors are positive, you'll need to be aware that such a person will need some adaptation time. When transitioning your environment to Agile, stay away from these types. You'll want new hires to bring in strong Scrum knowledge, and these really won't have it.

Another clarification would be to ask the candidate about his or her team makeup. Are they used to working with embedded business analysts? Are they working with a product owner who participates in their team meetings? How are the stories defined? Do they work with user experience (UX) teams? I've interviewed business analysts who have no idea how to work within a Scrum team, and developers who couldn't tell you who their product owner was. This question actually helps you on two levels. You'll understand if they have worked on a legitimate Scrum team and also to what extent. Not all companies have been able to incorporate their UX and business analyst resources. This question will let you know their experience with that.

This category is not as easy to use to eliminate a candidate, but you need to know where you'll need to supply more support. If there's too much extra time required, maybe another candidate would be more suitable.

Ask about how they work on their team

Your candidate has flown through the first two filters, but there's still one more hurdle for Scrum resources: How do they work on their team?

A ScrumMaster candidate should say something like, "I work with the product owner to develop a plan and remove roadblocks." If they say, "I make sure all tasks are completed," here's a warning: You have a traditional Waterfall candidate on your hands. Agile teams are supposed to be self-managed, with ScrumMasters acting as servant leaders, not task checkers. Product managers who can't step away from managing all the details and pull back to removing roadblocks don't translate well into Scrum.

When interviewing developer candidates, they should talk about things like a potentially shippable product, working with the business analyst and the product owner to understand stories, self-organizing teams, relative sizing, etc. Developers who don't mention the way the team works and how the product is delivered differently could also potentially be coming from more traditional project environments in which they could disappear for months to develop what they understood the feature to be.

Although not necessarily always a factor, you can also listen for such words as I versus my team. People who have worked on Scrum teams for a while will adopt the "team" phrasing because individual efforts become team efforts. Of course it is an interview, and the resource is trying to inform you of their skills, but if they're also using "my team" to describe their contribution, you'll know they're on a team that was unified, which might make them a good candidate.

Determining the nuances of the candidate's background can be difficult, but each filter will help you determine more about how well he or she will succeed. Come up with questions to assist you in understanding how the candidate will fit in your environment. If you find candidates lacking in this category, you're going to spend time retraining them in how to work within a Scrum team. They've potentially been trained incorrectly, or they are just not a good fit for Scrum. The ScrumMaster in my scenario above had no more interviews, because I knew she had no idea how to be a good ScrumMaster.

What are their Scrum observations?

Your candidate has done well up to this point, and if you were hiring for a general Scrum employee, you'd already be working on the offer; however, for this role, you need a bit more. You are looking for a resource to take a leadership role in the team. This may be a development lead, ScrumMaster, or product owner. How do you make sure that they have "that something more" that can bring a lot of value to the team? Ask them about their Scrum observations. This is a chance for the candidate to really show his or her experience and commitment to Scrum.

Here's where you'll hear things like:
  • "Scrum enables my team to plan better by . . . "
  • "To help us manage scope within iterations, we . . . "
  • "Our product owner is not engaged with our team, and that causes . . . "
I really enjoy the responses to these questions. I get to hear how the different disciplines see things from their perspectives. When you hear these answers, you'll know how strong a leader your candidate would make.


Finding the right candidate is never easy, but Scrum requirements put a unique spin on what is needed. The flexibility that companies appreciate also creates challenges, as these employees transition from company to company. I hope these steps will provide you with a framework to assist in your search.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.7 (6 ratings)


Sayi Sarat Chandra Parvatam, CSP,CSM,CSPO, 12/1/2015 8:40:09 AM
I liked this article the reason being you brought a different flavour and dimension altogether in terms of identifying the right candidate for the company. Also scrum helping here is something I admire about - Good one :) Looking forward for more and more articles from you in future :) - Thank you
Tim Baffa, CSM, 12/3/2015 1:45:06 PM
Kathy, this is an excellent article! I only wish there were other companies that also employed this level of Scrum understanding when recruiting candidates.

Very often, companies looking for Scrum Masters will fall back on what they know (comfort level). That ends up being typical PM skills and experience, and not the many critical and valuable Scrum Master attributes you've outlined here.
Robert Day, CSM, 12/14/2015 5:16:20 AM
Tim is completely right. When I was contracting, I went to a number of companies who were asking for ScrumMasters but really wanted PMs. I actually terminated one interview, saying "I am not the ScrumMaster you are looking for." It would also help if recruitment agencies had a better idea of what Scrum actually was, even if sometimes that meant their engaging a little more robustly with their clients at the person specification stage...
Ronald van Vliet, CSM, 1/13/2016 12:43:11 AM
Dear Kathy, thank you for your concise and clear article. I do however regret the fact that you use the term 'resource' when talking about people (although you also use the words candicate or employee). I would like to point out that people are not resources. Resources are 'things', like raw materials, hardware, furniture. Resources are interchangeable. People are not. They are unique. That's also why you are searching for 'the right candidate'. So could you please refer to your candidates as being people instead of resources?
Anonymous, 1/13/2016 4:23:13 AM
Hi Kathy,
Thank you. This is very interresting.
On the other side : I wanted to say that this is also a problem for a person who do scrum to find companies/teams that do scrum in a 'logical' way.
Most usage of scrum I saw in my career were adaptations of a pure waterfall model with the conclusion of telling that scrum doesn't solve problems. And most of the time, they were convinced to do scrum the right way.
Some kind of evangelism must still be done, I guess.

To do scrum is not so compicated when you understand it.
To convince to do scrum is more complicated.

Anyway, thank you again for sharing your expertise.

Kind regards
Meghan Robinson, CSM,CSPO, 3/17/2016 4:10:12 PM
Would you be okay with us highlighting this article on our new AgileCareers Blog?

You can view the blog here:

I look forward to hearing your response! Thanks.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up