_guides/AgileContracts_Interview_Questions_for_Agile_Roles.md
---
title: Agile Contracts - Interview Questions for Agile Roles
category: Agile
audiences:
- Developers
- Designers
- Project Managers
---
{::nomarkdown}
<style>
table {
width: 100%;
table-layout: fixed;
}
</style>
{:/}
This content provides scenarios and questions that are intended to guide the the government representative during the interview and evaluation phase where a candidate is being considered for an Agile delivery role. These sample questions can be used to evaluate and assess the overall experience, competency and compatibility of a candidate (Federal or contractor) being considered for specific roles in Agile methodologies (e.g. Scrum Master, Product Owner, developer, tester, etc.)
{::nomarkdown}
<div class="usa-accordion">
<ul class="usa-unstyled-list">
<li>
<button class="usa-button-unstyled" aria-expanded="false" aria-controls="question-1">
Scrum Master Interview Questions
</button>
<div id="question-1" class="usa-accordion-content">
{:/}
The Scrum Master (SM) is responsible for facilitating and maintaining the Scrum process and the overall health of the process and team. The Scrum Master performs this role by administering the Scrum ceremonies, facilitating the organic self-organization of the team, and removing any obstacles that may be impeding the team’s progress.
**Below are some of the basic Scrum Master Interview Questions when vetting a candidate for this position:**
|**Interview Questions**|**Agile Response Samples**|
|---------------|---------------|
|How do you differentiate your role as a Scrum Master against the Project manager or the Product Owner role?|{::nomarkdown}<ul><li> The primary role of the SM is not meant to “manage” the team or the project, but to guide the Scrum process and encourage self-organization. The Scrum Master has authority over protecting the team from outside influences, including from the Product Owner.</li> <li> Whereas, the Product Owner role is to guide the vision and the development process through backlog prioritization and management. The Product Owner role has the autonomy over the product and its requirements. </li><li> The Project Manager role (if applicable) in Agile projects on the other hand, shifts from command and control to management of resources, risk and dependencies across teams and removing obstacles.</li></ul>{:/}|
|How do you facilitate the creation of an effective scrum team? What does your ideal Scrum team look like?| {::nomarkdown}<ul><li>Ensure team size does not exceed the three to nine members size to ensure effective communication.</li> <li> Team members have cross-functional skills (ideally not the job titles) and are equipped to deliver the full product/project (e.g. of a software development team includes, software developers, architects, programmers, analysts, QA experts, testers, UI designers, etc.) </li> <li> The goal of the Scrum Master is to make it easy for team members to collaborate and avoid too many handoffs and phases. </li><li> Protects the team's autonomy to determine capacity and estimate for their commitments and when to complete work.</li></ul> {:/}|
|How do you help the team set sprint goals? | {::nomarkdown}<ul><li> Understands that a sprint goal summarizes the desired outcome of an iteration. It provides a shared objective, and states why it’s worthwhile undertaking the sprint.</li> <li> Ensures the PO and the team get together to refine and prioritize requirements </li> <li> Facilitates the process for the team to reach an agreement and commit on the items to be completed within the sprint.</li><li> Ensures any change to the sprint commitment is prioritized and agreed with the team. </li></ul> {:/}|
|Why and how do you conduct the Daily Scrum meeting?| {::nomarkdown}<ul><li>The daily scrum meeting provides the team an opportunity to communicate progress and surface impediments/dependencies. </li> <li> The SM understands these Stand-up sessions are to surface issues and not fully resolve or discuss them in the meeting.</li> <li> Limits the stand-ups to 10-15 minute time-boxes </li><li>Makes it a priority to follow-up and remove obstacles surfaced by the team after the stand-up. </li><li> The SM encourages participation of all team members who are actively working on the product </li></ul> {:/}|
|What is your experience with guiding teams with estimation?| {::nomarkdown}<ul><li> Help the team identify ambiguity in requirements: ensure the team has a full understanding of the requirements for which the task items are being estimated </li> <li> Ensure all team members are represented and actively participating in the estimation process </li><li> Experience with various estimation tools and techniques. Understanding of and can provide examples of estimation approaches and relative sizing (e.g. ability to explain the Fibonacci scale and story pointing, relative estimation, planning poker, etc.) </li></ul> {:/}|
|If the team’s work doesn’t get completed in a sprint, what would you do?| {::nomarkdown}<ul><li> <li> Does NOT plan increase the length of that sprint as it is a time-box the team agreed to respect and commit to. retrospectives for continuous improvement. </li> <li> Push unfinished work to the next sprint to be re-prioritized against future backlog items. </li> <li> Understanding that unfinished work within this timebox is usually a symptom of other issues, such as, change in scope, reduced capacity after sprint planning, poor estimation, etc. and the SM plans to help the team reflect and surface the issue and address them as part of their retrospective </li></ul> {:/}|
|What is your experience with reporting and metrics?| {::nomarkdown}<ul><li>Ability to understand and guide leadership in setting relevant metrics that are aligned with the objectives of the product. </li> <li>Basic understanding of Agile Metrics, such as, percentage of tasks completed, percentage of work accepted, Story Cycle Time, Defect Density, code coverage, team velocity, etc.) </li> <li> Ability to explain the difference between a BurnUp and a BurnDown </li> <li> A basic understanding of tools used to develop and deliver such metrics - the use of a scrum board, reporting dashboards and tools (JIRA, VersionOne, etc.) </li></ul> {:/}|
|How do you help your teams continuously improve and reach their product/sprint goals?| {::nomarkdown}<ul><li>Guiding, facilitating and following up on action-items for removing impediments and dependencies </li> <li> Guiding and facilitating the development and implementation of team working agreements, e.g. acceptance criteria, the definition of of ready and definition of done, etc. </li> <li> Encouraging and facilitating the team to learn Agile development best practices such as Test Driven Development (TDD), pair programming, etc.</li></ul>{:/}|
{::nomarkdown}
</div>
</li>
<li>
<button class="usa-button-unstyled" aria-controls="question-2">
Product Owner Interview Questions
</button>
<div id="question-2" class="usa-accordion-content">
{:/}
The Scrum Product Owner (PO) is the primary project key stakeholder. The primary role of the product owner is to have a vision of what needs to be built, and convey that vision to the scrum team. The Product Owner is the lead champion of the product and is responsible for ensuring the product creates value for its customers and users as well as the company providing it. The PO does this through the product backlog, which is a prioritized features list for the product.
**Below are some of the basic Product Owner interview questions when vetting a candidate for this position:**
|**Interview Questions**|**Agile Response Samples**|
|---------------|---------------|
|How would you characterize your role as a Product Owner?|{::nomarkdown}<ul><li> The primary role of the PO is to guide the vision by translating it into workable business or technical requirements.</li> <li> The PO has an in-depth product knowledge and autonomy to prioritize product vision and requirements.</li> The PO responsibilities include: <li> Creating and maintaining the Product Backlog</li><li> Prioritizing and sequencing the Backlog according to business value as expressed by roadmap and stakeholder needs</li> <li> Preparing for each sprint and release planning by working with team to elaborate Feature Stories into Minimal Marketable Features that deliver increments of value and User Stories that are appropriately sized for each sprint.</li> <li> Representing customer and stakeholder interests, by engaging and soliciting feedback to validate priorities and compromises.</li> <li> Participating in daily standup Scrums, Sprint Planning Meetings, Sprint Reviews, and Retrospectives.</li> <li> Developing acceptance criteria and accepting User Stories during the sprint to confirm implementation meets intent of acceptance criteria. </li> <li> Negotiating Sprint priorities and commitment when team communicates new discoveries that impact size or value of work.</li><li> Communicating status to stakeholders including use of Visible Product Backlog for forecasting release content and dates.</li></ul>{:/}|
|What is the difference between a Product Backlog and a Project Backlog?| {::nomarkdown}<ul><li> <b>Product Backlog:</b> evolves throughout the product lifecycle. Requirements will be added, removed and prioritized on an ongoing basis so long as the product is still being maintained. </li> <li> <b>Project backlog:</b> A project backlog is about the creation of an item with limited scope for a given delivery. When that feature/objective is met, the project is done. It is limited to the scope of the project. </li></ul>{:/}|
|Describe your role as a PO in the Scrum Ceremonies/meetings?| Understands that the PO is integral in keeping the team on track and plans to be an active and regular participant in the collaborative activities and meetings. {::nomarkdown}<ul><li> <b>Sprint Planning:</b> the PO will have a prioritized product backlog that is ready to be discussed and is clarify each item with the development team, to enable the team to collectively estimate the effort involved. </li> <li> <b>Sprint Review (demo):</b> PO presents the completed product increment to Stakeholders and gathers feedback. Prioritizes the new feedback against the product backlog to determine work for the next iteration </li> <li> <b>Daily Stand-up:</b> PO can attend to provide support to the team by removing blockers/impediments on requirements.</li><li> <b>Sprint Retrospectives:</b> PO can attend to contribute factual information about process improvements in the team’s process and support continuous improvement.</li></ul>{:/}|
|What is your approach to creating and managing product roadmaps?|{::nomarkdown}<ul><li> Focus is on the vision or objective, as opposed to granular feature details.</li><li> Plans to develop a road-map that is lightweight, articulates and validates the product strategy—the path to deliver the vision </li> <li> Approaches to ensure stakeholder engagement and secure buy-in.</li><li> Approaches to measure the roadmap</li><li> Plans to regularly review and adjust the roadmap </li></ul>{:/}|
|What does a typical day look like as an Agile Product Owner?|{::nomarkdown}<ul><li> On the Team: guide the product vision, prioritize and refine product backlog, Just-in-time requirement clarification, Review and accept requirements </li> <li> With stakeholders: gather requirements, set reasonable expectations, manage requirements, report progress consistently, acquire and include feedback. </li></ul>{:/}|
|How do you manage changing requirements?| Plans to employ Agile approaches to managing changes in requirements, such as: {::nomarkdown}<ul><li> Implements / follows a process that allows for feedback and changes to flow through the PO. </li> <li> Determines the scope of the change and the scope of incorporating the change </li> <li> Implements / follows a transparent change approval process to gain approval or rejection of the change </li><li>uses the agile framework e.g. product backlogs and sprints to communicate and implement approved change requests, and keeps change logs in a shared / visible platform. </li></ul>{:/}|
|How do you avoid misallocating resources to features or products that are NOT a priority? |{::nomarkdown}<ul><li> Has an understanding of the Agile/Lean concept of “maximizing the work not done”. I.e. building working increments just enough to deliver a minimum viable product (MVP) and get feedback, keeping design simple, deprioritizing features that do not provide value to the end user, are duplicates or add a lot of cost to the product, etc. </li> <li> Feels comfortable to challenge and say “no” to stakeholder feature requests that are not aligned with overall product goals/objectives, and communicate accordingly.</li></ul>{:/}|
|What would you say are the most important skills for a PO? |{::nomarkdown}<ul><li> Communication: ability to solicit product objectives, clearly articulate the connections between larger business goals and small backlog items to the team and consistently managing expectations. </li> <li> Analysis and prioritization: in-depth understanding of the business and the product for effective prioritization of customer needs, and to maximize the value of the product. </li> <li> Ability to breakdown and split big slices of value into small slices of value</li><li>The ability to challenge stakeholders’ feedback in light of the ultimate product goal</li></ul>{:/}|
{::nomarkdown}
</div>
</li>
<li>
<button class="usa-button-unstyled" aria-controls="question-3">
Developer Interview Questions
</button>
<div id="question-3" class="usa-accordion-content">
{:/}
|**Interview Questions**|**Agile Response Samples**|
|---------------|---------------|
|How would you say Agile development impacts the programming design and development process?| {::nomarkdown}<ul><li> In Agile environments, there is no single role or person on the team that is in charge of design. The design and development process are intertwined. Developers are also designers and team members alternate between designing, developing and testing throughout the entire development process. </li> <li> Such consolidated development and design reduces errors and improves productivity because developers don’t have to interpret designs or seek clarification from designers before they write the code. </li></ul>{:/}|
|How long is a typical sprint cycle when you are breaking work down and estimating?| {::nomarkdown}<ul><li> A typical sprint cycle should be 2 - 3 weeks maximum. </li> <li> Agile requires frequent feedback from project owners, short sprints give the Product Owner and users a chance to make adjustments while giving developers a chance to react throughout the development cycle. </li><li> Short sprints also give the entire team a chance to fix coding or quality issues early. </li></ul>{:/}|
|What would you say are the most essential programming best practices within the Agile development frameworks?| An in depth understanding of the nature of Agile development and delivery process such as: {::nomarkdown}<ul><li> Familiarity with various Agile frameworks and the role of developer in each, interfacing with different layers of the development framework </li> <li> Knowledge and understanding of test driven development and continuous integration </li><li> Setting up the development environments, build automation e.g. unit testing (tools – NUnit, JUnit ), continuous integration tools, code-smell concepts, refactoring concepts, code coverage concepts and tools, code review concepts and tools, etc.</li></ul>{:/}|
|What is your experience writing automated test cases? | {::nomarkdown}<ul><li> Experience and ability to discuss automated regression testing, continuous integration and testing, performance testing techniques and tools. </li> <li> Understands and is able to articulate the benefits of automated testing, such as, quick identification and isolation of development defects as well as the ability to test development work completed in previous iterations. </li><li> Addresses the need for manual testing as well as automated testing, understanding and comfortable with the changing nature of the code base in Agile. </li></ul>{:/}|
|What is your experience with continuous integration? | Detailed explanation of how continuous integration is used on previous projects{::nomarkdown}<ul><li> Continuous integration is a set of automated builds, integration and test steps that executes against the code base in a configuration management repository. For instance, using Java and CVS repositories setting triggers that automatically built, integrated and unit tested the code often and every time someone checks in new code. </li></ul>{:/}|
|How did you manage traceability of the requirements?| {::nomarkdown}<ul><li> Understands code is developed to ultimately deliver business/technical needs and develops code that meets the requirements defined in the story card / use case. </li> <li> Understanding of the need to determine if functions by the developer work in the way the business wanted it to function when developing a testing plan for functionality created by the developer during an iteration. </li><li> Ensures team members understand the importance of this concept and if they understand and accept traceability for the team to meet project goals.</li></ul>{:/}|
|How do you handle changing requirements?| {::nomarkdown}<ul><li> Ensures change is flowing through the product owner and is prioritized accordingly. </li> <li> Doesn’t accept and start working on change outside the team. Understands Team members need to regroup to reevaluate and welcome changes into their development cycle using sprint planning. </li><li> Comfortable with the general idea that requirements can change a lot while design is being refined, and participates in the design process with a problem solver attitude.</li></ul>{:/}|
|How do you understand team velocity to measure team capacity?| {::nomarkdown}<ul><li> Team velocity is the rate at which a team is completing or "burning" through story points. For instance, an average velocity of 25 story points per iteration means that so far, the team has been able to identify, code and test 25 units of functionality (story points) in an average iteration and can expect to do about that much in future iterations, all other factors remaining constant.</li></ul>{:/}|
|What would you say are the most important skills for an Agile developer?| Technical:{::nomarkdown}<ul><li> Programming with intention: problem solving and supporting the business and technical needs </li> <li> Design thinking: avoid over and under-design</li><li> Considers testability before writing code</li><li> Succeed with Acceptance Test Driven Development </li><li> Minimizes complexity and rework</li><li> Knows when and how to use inheritance/legacy </li><li> Continuous learning attitude to developing and delivering standards and best practices (including learning from peers) </li>Behavioral:<li> Communication, collaboration, time management/ planning, problem solving, conflict management, flexibility to changing requirements, decision making, diplomacy </li></ul>{:/}|
{::nomarkdown}
</div>
</li>
<li>
<button class="usa-button-unstyled" aria-controls="question-4">
Tester Interview Questions
</button>
<div id="question-4" class="usa-accordion-content">
{:/}
|**Interview Questions**|**Agile Response Samples**|
|---------------|---------------|
|How is Agile Testing different from traditional testing models, in light of the role of the tester?| {::nomarkdown}<ul><li> The main difference in Agile environment is that testing is not a phase, it is an activity parallel and intertwined in the development process </li> <li> The role of a software tester in Agile goes beyond “just testing” and logging bugs. It is more working as part of a development team and working closely with the product owner. The tester works with everyone in the team in order to improve and build quality into the product as early and as often as possible.</li><li> The tester has the required technical experience to make suggestions and give input on automating nightly builds, Integration, and regression, as well as exploratory and acceptance testing </li><li> Agile testing also involves all members of an agile team with special skills, such as test automation. </li></ul>{:/}|
|How do you decide what to test, and how to thoroughly to test?| One approach is to identify and analyze the most and least important in the delivery product. Consider rational inclusion/exclusion criteria based on the product such as; {::nomarkdown}<ul><li> Building a broad testing coverage </li> <li> Identify major features users will actively interact with </li><li> Identify the most complex and potentially problematic components in the system </li><li> Consider prioritizing several test cases that have higher business value and are cheaper to execute as opposed to one big expensive test </li><li> Test cases which cover new features bring more incremental use than those covering partly old and partly new features, it is ideal to incorporate both </li></ul>{:/}|
|What is your testing approach when requirements change continuously?| Some possible answers can be; {::nomarkdown}<ul><li> Write generic test plans and test cases which focus on the intent of the requirement rather than its exact details </li><li> Work very closely with the product owners or business analysts to understand the scope of change so testing can be estimated and planned accordingly</li><li> Makes sure test cases are updated and automated with changing requirements to minimize the risk of issues, and outdated test cases, especially as the project nears its end.</li></ul>{:/}|
|What types of testing are you familiar with?| Examples of the various types of testing in Agile development include; {::nomarkdown}<ul><li> <b>Unit Testing:</b> the testing of an individual unit or group of related units. Usually completed by the programmer to test that the unit he/she has implemented is producing an expected output against a given input.</li> <li> <b>Functional Testing:</b> testing to ensure that the specified functionality required in the system requirement works. </li><li> <b>System Testing:</b> testing to ensure that by putting the software in different environments (e.g., Operating Systems) it still works. System testing is done with full system implementation and environment.</li><li> <b>Integration Testing:</b> a group of components are combined to produce output. If software and hardware components have any relation then the interaction between software and hardware is also tested in integration testing.</li><li> <b>Regression Testing:</b> Regression testing is the testing after modification of a system, component, or a group of related units to ensure that the modification is working correctly and is not damaging or imposing other modules to produce unexpected results.</li><li> <b>Stress Testing:</b> testing to evaluate how system behaves under unfavorable conditions. Testing is conducted at beyond limits of the specifications.</li><li> <b>Performance Testing:</b> the testing to assess the speed and effectiveness of the system and to make sure it is generating results within a specified time as in performance requirements. </li><li> <b>User Acceptance Testing (UAT):</b> often done by the customer or Prod to ensure that the delivered product meets the requirements and works as the customer expected.</li><li> <b>Beta Testing:</b> conducted by a team outside development, or publicly releasing full pre-version of the product which is known as beta version to be tested by end users. The aim of beta testing is to cover unexpected errors. </li></ul>{:/}|
|What is Test Driven Development (TDD)?| {::nomarkdown}TDD is an approach where the development team first writes automated test cases which describe new functionality cases and creating small codes to pass that case. Followed by the refactoring of the code to meet the test criteria.{:/}|
|What is your experience writing automated test cases?| {::nomarkdown}<ul><li> Experience and ability to discuss automated regression testing, continuous integration and testing, performance testing techniques and tools such as test stubs, etc. </li> <li> Understands and is able to articulate the benefits of automated testing, such as, quick identification and isolation of development defects as well as the ability to test development work completed in previous iterations. </li><li> Understanding and comfortable with the changing nature of the code base in Agile. </li><li> Addresses the need for manual testing as well as automated testing.</li></ul>{:/}|
|What is your experience with Agile frameworks? | {::nomarkdown}<ul><li> Knowledge and experience working with Scrum, Kanban, Lean, etc. frameworks </li> <li> Understanding of common artifacts in Agile environments like the Product backlog, team velocity, definition of done, pair programming, test automation, etc. </li></ul>{:/}|
|What would you say are the most essential skills for an Agile tester?| {::nomarkdown}<ul><li> Continuous attention to technical excellence and eye for good design enhancements and agility </li> <li> Ensures requirements and test criteria map to the technical or business requirements or acceptance criteria </li><li> Technical knowledge and experience to contribute to the team in the form of code review, requirements/user stories grooming, or coding where it is tenable </li><li> Test management and automation scripts: creating, running and managing automated test scripts. </li><li> Test environment setup, some database Knowledge and understanding of testing concepts such as stub - A small code which mimics a specific component in the system and can replace it. Its output is same as the component it replaces. </li></ul>{:/}|
|What qualities / attributes should a good Agile tester have?| {::nomarkdown}<ul><li> Attention to detail, ability to detect and question ambiguity, creativity to help expose hidden bugs and determine all the scenarios that are likely to detect a defect. </li> <li> Seeks to understand the requirements quickly and understand the risk/opportunities around with changing requirements. Seeks to prioritize test work based on such requirements. </li><li> Communication, collaboration, time management/ planning, problem solving, conflict management, flexibility to changing requirements, decision making, diplomacy </li><li> Understanding of Agile concepts and principles, plans to actively participate in daily sprint planning, stand-ups, retrospectives. </li></ul>{:/}|
{::nomarkdown}
</div>
</li>
</ul><!--.usa-unstyled-list-->
</div><!--.usa-accordion-->
{:/}
---------------------------------------------------------------------------------------------
**Additional Reference**
* [Scrum Master Interview Questions](http://www.agilelove.com/methodologies/scrum/scrum-master-interview-questions/)
* [42 Scrum Product Owner Interview Questions](https://age-of-product.com/42-scrum-product-owner-interview-questions/)
* [How to Manage Change Requests](http://www.bridging-the-gap.com/how-to-manage-change-requests/)
* [7 Skills You Need to Be a Great Product Owner](https://www.scrumalliance.org/agile-resources/7-skills-you-need-to-be-a-great-product-owner)
* [Maximizing the Amount of Work Not Done](https://www.scrumalliance.org/community/articles/2015/august/maximizing-the-amount-of-work-not-done-is-%E2%80%93-essent)
* [Essential Skills for the Agile Developer](https://www.agilealliance.org/resources/sessions/essential-skills-for-the-agile-developer/)