Scrum Master / Agile Project Lead (SMB) Hiring Guide

Attention to Detail Tasks

To objectively test attention to detail, present tasks where candidates must spot errors or inconsistencies in typical Scrum artifacts or data. Here are a few deterministic task ideas (with exact data or setups) and the expected outcome:

Sprint Burndown Anomaly: Provide a table of "Remaining Work" over a 2-week sprint, for example: Day 1 - 40 points; Day 2 - 35; Day 3 - 37; Day 4 - 30; Day 5 - 25; Day 6 - 20; etc. Ask: "On which day does the data indicate a likely problem, and why?" The correct answer is Day 3, because the remaining work went up from 35 to 37 - a clear anomaly. This suggests that scope was added or a task was re-estimated upward on Day 3, which a Scrum Master should notice and investigate. (Scoring is binary: candidate must identify Day 3 and mention "work increased" or "scope change" as the reason.)

Backlog Prioritization Check: Present a short product backlog list with priority rankings, for example:

User can reset password (High priority)

Admin dashboard analytics (High priority)

Improve UI color scheme (Medium priority)

Add multi-factor login (High priority) Ask: "What is the inconsistency in this ordering?" The answer: "Add multi-factor login" is marked High priority but appears below a Medium item, which is out of order. A detail-oriented Scrum Master should spot that a high-priority item is incorrectly ranked below a medium. (Deterministic scoring: identifying that Item 4's placement is the mistake earns full points.)

User Story & Criteria Mismatch: Provide a user story with acceptance criteria that contain a subtle inconsistency. For example: User Story: "As a customer, I want to receive a text message to reset my password so that I can regain access if I forget it."

Acceptance Criteria:

• "Given I am on the reset page, when I enter my email and submit, then I receive an email link to reset my password." Ask: "Identify the discrepancy between the story and its acceptance criteria." The correct answer: The story talks about a text message (SMS) reset, but the acceptance criteria describe an email reset. This is a contradictory detail. (To score full points, candidate must point out that one says SMS and the other email - a critical reading detail a Scrum Master should catch before work proceeds.)
• Velocity Calculation Task: Tell the candidate: "Team A completed 20 story points in Sprint 1, 22 in Sprint 2, and 18 in Sprint 3. The product backlog has 60 points of work remaining. Assuming similar velocity, approximately how many sprints will it take to finish the backlog?" This is a straightforward calculation of average velocity (~20 points/sprint) and backlog division. The expected answer is 3 sprints (since at ~20 points per sprint, 60 points ~ 3 sprints). This tests basic numeracy and understanding of velocity. (Scoring: only accept "3 sprints" or an answer in the range of 3, with possibly an explanation of averaging 20 points). Each of these tasks has a precise correct answer, making grading objective. They simulate the kind of detail-checking a Scrum Master does (catching data oddities, alignment issues, or doing quick planning math). A high-performing candidate should get most or all of them correct quickly.

Scoring: Each question is 1 point. Both have a single correct observation. Total 2 points. A detail-oriented candidate catches both; one who misses one of these likely has lower attention to detail.

Overall Test Scoring: The assessment totals 4 + 3 + 4 + 4 + 2 = 17 points. For ease, this could be normalized to 100%. A suggested passing threshold might be ~12/17 (70%). However, scoring should also consider any "must-have" areas (see Scoring Guidance below).

Strong communication is vital for a Scrum Master. Here are real-world writing prompts to assess a candidate's ability to communicate clearly and appropriately in typical scenarios. Each prompt expects a short written response (like an email or Slack message). The content can be evaluated for clarity, tone, and completeness against a gold-standard answer.

• Stakeholder Update Email: "Write a brief email to a key business stakeholder explaining that the team will not meet a sprint goal (a feature will be delayed). Include the reason, your plan to address it, and maintain a tone that manages expectations while preserving trust." Expected Response Traits: A good answer will openly state the slip ("we won't finalize Feature X by end of sprint"), give a concise reason (e.g. unanticipated complexity or a blocking issue), and crucially outline a recovery plan ("we have prioritized it for the next sprint and added an extra testing step to ensure quality"). Tone should be factual but solution-oriented and empathetic: e.g. "I understand this feature is important; we are working to minimize the delay and ensure it meets your needs." No defensiveness or blaming - instead accountability and reassurance. (Score by checklist: mentions delay, reason, next steps, and maintains professional tone.)
• Team Motivation Slack Message: "Compose a Slack message to your Scrum Team after a sprint where not everything was completed and morale seems low. Your aim is to acknowledge the shortfall but also highlight positives and encourage the team for the next sprint." Expected Response Traits: The model answer might say something like: "Hey team, we made great progress on several stories even though we didn't get to finish all of them. I appreciate everyone's hard work - for example, the refactoring John did will pay off long term. Let's discuss in retro how to tackle the spillover and adjust for next sprint. Proud of the collaboration I saw this week - let's keep improving! .." The tone should be positive, supportive, and forward-looking, without ignoring the issue. It should avoid chastising; instead it emphasizes learning and team unity. (Scoring focuses on positive reinforcement and constructive forward focus in the message.)
• Clarification Request Email: "Draft an email to the Product Owner to clarify an ambiguous user story. The story, 'Improve search performance,' is vague. Ask the PO for the necessary details or acceptance criteria in a polite and precise manner." Expected Response Traits: The candidate's email should be courteous and clear about what info is needed: e.g. "Hi [PO Name], regarding the 'Improve search performance' story - could you please clarify the target metrics or specific improvements you have in mind? For instance, are we aiming to reduce search time by a certain percentage, or handle more concurrent users? Also, any particular user scenarios we should focus on? This will help the team ensure our solution meets your expectations." The email should avoid agile jargon the PO might not know, use a helpful tone, and show understanding of the business need behind performance. It should encourage a response by being specific in questions. (Score by whether the email clearly identifies what is unclear and asks concrete questions, all in a respectful tone.)
• Retrospective Outcome Summary: "After a Sprint Retrospective focused on improving QA processes, write a short summary message to the team capturing the agreed action items (e.g. 'create a testing checklist') and thanking them for their input." Expected Response Traits: A top answer would succinctly list the actions: "Team, thanks for the very productive retrospective today. Just to summarize, we identified and agreed on a few action items to boost quality: (1) Testing Checklist - Alice will draft a checklist for peer review by next Tuesday; (2) Pair Testing - we'll pilot one session mid-sprint where two devs test each other's work; (3) Definition of Done Update - include performance test pass criteria. I'll help facilitate these and follow up on progress. Great insights from everyone - let's keep this continuous improvement going!"* The tone is appreciative and empowering. (Score on inclusion of key actions and positive reinforcement of team effort.) Each communication prompt is evaluated for clarity, tone, and effectiveness. The expected answers use plain, neutral business English (no slang or overly technical language unless appropriate), get to the point, and show emotional intelligence (empathy, encouragement, courtesy). Marking can use a rubric (e.g. 5 points: all key information and excellent tone; 3 points: minor info missing or slightly off tone; 0 points: major omissions or inappropriate tone).

Tasks (Deterministic Simulation Cases)

These tasks simulate challenges requiring the Scrum Master to apply their process knowledge step-by-step. Each is designed so that an ideal answer can be compared to a clear expected solution path:

• Scenario: Removing an Impediment - "A team member reports they cannot progress on a story because they're waiting on input from an external vendor's API, which is delayed. Outline step-by-step how you, as Scrum Master, would handle this impediment." Expected Steps (Gold Standard): Assess and Clarify the Blocker: Speak to the team member to get details about the API issue (since when, what exactly is needed, who is the vendor contact). Ensure it's recorded in the impediment log.

Communicate and Collaborate Externally: Reach out to the vendor or appropriate point of contact (or facilitate the team member/PO doing so) to understand the timeline for a fix or data delivery. If necessary, escalate through management if the vendor is a third-party under contract.

Adjust the Sprint Plan: Discuss with the Product Owner options to rearrange work. Possibly swap the blocked story out of the sprint or bring in another story if the delay will be significant. Ensure the team member has alternate tasks so they're not idle (maybe pair them with someone else in the meantime).

Inform the Team and Stakeholders: Let the team know the impediment and the plan (transparency). Update any relevant board or tracking tool to indicate the story is blocked. If the impediment might impact the sprint goal, also inform stakeholders that this risk is being managed.

Follow Up Until Resolved: Continuously track progress on the blocker - set a reminder to check in with the vendor daily. If the vendor issue resolves, communicate that immediately and help the team member get back on track. If it doesn't, be prepared to carry over the story and note it in the sprint retrospective for process improvement (e.g. "how can we reduce external dependency impact?"). Deterministic Scoring: Candidates must cover the essence of these steps - identifying the issue, communicating externally, replanning internally, keeping everyone informed, and following through.

Each major step present earns credit; missing a critical step (like not addressing what the team should do while waiting) would lose points.

• Scenario: Mid-Sprint Major Change Request - "Midway through a sprint, the CEO directly asks the team to add a critical hot-fix item that wasn't in the sprint plan. Describe how you handle this situation step by step within Scrum principles." Expected Steps: Acknowledge and Gather Details: Thank the CEO for the information and get details about the urgency and impact of the hot-fix. Determine if it truly cannot wait until next sprint (is it a production outage? a compliance issue?).

Engage the Product Owner: Immediately involve the Product Owner, as they own prioritization. Discuss the new request's priority relative to the current sprint goal. If it's genuinely top priority, the PO and team will decide how to adjust scope.

Evaluate Trade-offs with the Team: Convene a quick team huddle. Present the new request and time frame. Ask the team to estimate the effort. If they take it on, what will they drop from the sprint to stay within capacity? Scrum Master facilitates this discussion, ensuring the team is not simply forced to "do it on top of everything else."

Adjust the Sprint Commitment (if needed): If the decision (with PO approval) is to include the hot-fix, remove or defer an equivalent amount of work (one or more stories) from the sprint. Update the sprint backlog accordingly. If the team decides not to include it now (e.g. it's not as urgent as thought), communicate that respectfully back to the CEO with rationale and when it will be addressed.

Communicate and Document: Inform the CEO (and any relevant stakeholders) of the plan - e.g. "We've rearranged the sprint to address the hot-fix by Friday, and pushed out Feature Y to next sprint to accommodate this." Ensure Jira/Trello reflects these changes (possibly mark the swapped out story as moved to backlog or next sprint, and add the new item). Maintain transparency.

Protect the Team's Focus: Once the decision is executed, refocus the team on the revised sprint scope. As Scrum Master, help minimize thrash - ensure everyone understands the new priority and remind outside stakeholders that further changes must wait. Scoring: The ideal answer shows balancing stakeholder urgency with agile discipline. Full points for involving the PO, making trade-offs (not just accepting extra work blindly), and communicating clearly. If a candidate simply says "do whatever the CEO says and tell the team to work harder," that would be incorrect (fails to uphold Scrum values) 34 . The step-by-step structure allows partial credit if some but not all key actions are identified.

Scenario: Improving Sprint Retrospectives - "Your last few sprint retrospectives have felt superficial - the team isn't digging into root causes of issues, and the same problems (like 'testing delays') keep recurring. Design a step-by-step plan to make the next retrospective more effective and get to real improvements."

Expected Steps:

Prepare Data and Examples: Before the retro, gather some concrete examples and metrics from the sprint - e.g. "3 bugs slipped through to production" or "testing finished on average 2 days after development for each story." Bring this evidence to retro to spark deeper discussion.

Try a Different Format: Plan a fresh retrospective format to break monotony. For instance, use the "5 Whys" technique on a specific issue (like why testing delays happen) or an activity like "Start/Stop/ Continue" instead of a free-form discussion. Perhaps use a whiteboard or Miro to let people post anonymously at first if they're shy to speak.

Encourage Full Participation: At the retro, explicitly invite everyone's input. As facilitator, call on quieter members in a gentle way ("Alex, anything from your perspective on testing delays?"). You might use round-robin or have everyone write down thoughts first to avoid groupthink. Ensure psychological safety by emphasizing no idea is bad and that candor is welcome.

Identify Root Causes: Lead the team through analyzing one key issue deeply (e.g., testing delays). Ask "why" repeatedly or use cause-and-effect diagrams until the team uncovers a root cause (e.g. "we don't involve QA early enough" or "we lack a proper staging environment"). Avoid just listing symptoms; push for underlying reasons.

Develop Specific Action Items: For each major problem discussed, have the team agree on 1-2 concrete actions. For example, "Action: Developers will pair with QA for an hour on each story before marking it done" or "Set up a staging server by end of next sprint." Make sure these are assigned to owners and have target dates.

Follow Through: Conclude the retro by summarizing these actions and express optimism. After the meeting, document the retro outcomes and in the next sprint planning or Daily Scrums, remind the team of their commitments (e.g. "Remember, this sprint we're doing that QA pairing from day 1"). In the subsequent retro, check if those actions helped. Scoring: The model answer earns full credit if it outlines a clear plan touching on preparation, facilitation technique, engagement, root cause analysis, and action items. Partial credit if they mention some but not all (e.g. they say "try a new format and get action items" but miss discussing root cause analysis or team participation strategies). This tests the candidate's ability to not just run retros but continuously improve their efficacy.

Scenario: Introducing Kanban for Unplanned Work - "Your Scrum team in a tech startup also has to handle customer support tickets which arrive unpredictably, on top of their sprint work. These often disrupt sprint goals. Describe how you would integrate a Kanban approach to manage this support work alongside Scrum."

Expected Steps:

Acknowledge the Problem: Recognize that urgent support tickets are unplanned work and discuss with the team the impact on sprint commitments. Gain agreement that a separate flow might be needed to handle them without derailing everything.

Set Up a Kanban Board: Create a simple Kanban board (either a physical board or digital, maybe a Jira Kanban project or a Trello board) dedicated to support tickets. Columns could be "To Do (New) / In Progress / Done". This visualizes the support queue separate from the sprint backlog.

Establish WIP Limits & Policies: Work with the team to set a reasonable Work-in-Progress (WIP) limit for support work (e.g. no more than 2 tickets in progress at once) 35 . Define a policy like: If a new ticket comes and WIP limit is reached, it waits in queue or we swap it with a lower-priority one. Assign someone each day (perhaps a rotating "support buddy") to monitor and pull in tickets, so not everyone is interrupted simultaneously.

Allocate Sprint Capacity for Support: During sprint planning, account for expected support load by reserving some capacity (say 10-20% of the team's time) for ticket work. This means planning slightly less feature work. Make it explicit in planning that, for example, Developer X is the primary support responder this sprint (rotating each sprint).

Track and Adapt: Use the Kanban board metrics (arrival rate, cycle time of tickets) to inspect if the WIP limit and capacity allocation are working. In retrospectives, review how support work affected the sprint. If support overwhelms, adjust WIP limit or rotation frequency. If it's light, maybe more feature work can be taken on. The Scrum Master ensures this Kanban system and Scrum sprint planning stay synchronized (e.g. if a huge support issue arises, treat it like an unplanned backlog item and possibly re-plan the sprint). Scoring: Full marks for a solution that mentions a separate board or system for unplanned work, controlling WIP, and adjusting sprint planning to accommodate support. Points deducted if the answer ignores the need for limits (e.g. just says "we'll do both at once") or fails to keep transparency. This case assesses practical hybrid framework thinking, expected of an Agile Lead in an SMB where roles are fluid.

Each of these technical/process tasks has a clear "best practice" solution path. The expected answers are detailed above. Grading would compare the candidate's steps to the gold-standard steps: a near match earns full credit, partial steps earn partial, and critical omissions or counterproductive steps (e.g. violating Scrum principles) result in low scores.