 | Request for Demo Session |
| Watch Our Intro Video |
Blog AuthorStarAgile
PublishedNov 20, 2024
Views13,305
Read Time20 mins
StarAgile has gathered Scrum Master interview questions to give certified professionals an idea on type of questions which may be asked during interview. After Scrum Master Certification most of the professional will update their profiles and plan to attend Scrum master interviews these questions will be useful specially for these professionals.
These interview questions for scrum master are prepared by industry experts from StarAgile who trains on CSM certification.
The testers (developers) ensure that the whole process of testing (development) is broken into small steps as possible, and just a small unit of code is tested (developed) in each of these steps. The team of testers (developers) consistently communicates the results of their work and changes the short-term strategy and even the development plan on the go, based on the results of agile testing. Agile methodology encourages flexible and rapid response to change, which should lead to better end results.
The major differences are:
Master Certified Scrum Master Certification Bangalore with StarAgile – Enroll Now to Boost Your Career with Hands-On Training and Industry-Recognized Certification!
Scrum is a type of iterative model only but it is iterative + incremental.
Other Agile methodologies include – Kanban, XP, Lean
There are 3 major ceremonies performed in Scrum:
Planning Meeting – Where the entire scrum teams along with the scrum master and product owner meet and discuss each item from the product backlog that they can work on the sprint. When the story is estimated and is well understood by the team, the story then moves into the Sprint Backlog.
Review Meeting – Where the scrum team demonstrates their work done to the stakeholders
Sprint Retrospective meeting – Where the scrum teams along with the scrum master and product owner meet and retrospect the last sprint they worked on. They majorly discuss 3 things:
What went well?
What could be done better?
Also Read: What is Agile Project Management
Action Items
Apart from these three ceremonies, we have one more called “Backlog grooming” meeting. In this meeting, the scrum team along with the scrum master and product owner. The product owner put forward the business requirements as per the priority and the team discussed over it, identifies the complexity, dependencies, and efforts. The team may also do the story pointing at this stage.
Also Read: What is One Accountability of a Scrum Master?
The three Amigos are –
Also Read: What Is Scrum Teams
The ideal size is 7 to9 with +/- 2
Also Read: Scrum Master Career
Each day, at the same time and same place (in front of the task board), the team meets to give updates about their tasks and tickets resolved for the day. This meeting addresses SCRUM’s three questions listed below.
– What have you completed since the last meeting?
– What do you plan to complete by the next meeting?
– What is getting in your way?
Also Read: What Is Scrum Guide
It’s called “Sprint”
A Release candidate is a build or version of the software that can be released to production. Further, testing such as UAT may be performed on this version of the product.
Also Read: PMP vs Scrum
The key feature of agile are:
Also Read: How To Make The Best Of Your Daily Scrum Meeting?
Agile has a new breed of PM tools including Rally Software, Version One and XPlanner, EasyBacklog, iceScrum, Agilefant, Agilo. These tools bear no resemblance to the waterfall PM tools like MS-Project or Clarity.
Also Read: Scrum Master vs Product Owner
A Story Board is a visual representation of a software project’s progress. There are generally four columns ‘To do’, In Progress’, ‘Test’, and ‘Done’. Different colored post, its notes are placed in each column indicating the progress of individual development items. A storyboard is typically used in agile development.
Also Read: What Is Scrum Board
A Scrum Master should make this role their top priority to focus on benefits of the overall team. Their load will vary from sprint to sprint depending on what impediments and issues the team are dealing with. Newly formed teams typically take more Scrum Master time; 50%-100%, while experienced Scrum Masters with established well-functioning teams might spend 50% or less time on the Scrum Master role.
In Scrum, the focus is on delivering fully-tested, independent, valuable, small features. Thus, the risk is diversified and if one feature goes wrong, it should not impact another feature.
[read more=”Click here to Read More” less=”Read Less”]
Also Read: Scrum Development
It is recommended to have 2 – 4 weeks of sprint cycle.
Requirements are termed as “User Stories” in Scrum.
A Scrum Sprint is a regular, repeated work cycle in scrum methodology during which work is completed and made ready for review. Scrum sprints are basic units of development in the scrum methodology. Generally, scrum sprints are less than 30 days long.
Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.
During the Sprint:
No changes are made that would endanger the Sprint Goal.
Quality goals do not decrease, and the scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
Epic is a group of related user stories.
User Stories define the actual business requirement. Generally created by the business owner.
Task: To accomplish the business requirements, development team create tasks.
If capacity is measured as a percentage of 40 hours weeks then completed
= story points * team capacity
If capacity is measured in man hours then completed story points/team capacity.
The user stories are defined in the format of
As a <User / type of user>
I want to <action / feature to implement>
So that < objective>
Scrum Master – Acts as a servant Leader for the scrum team. He presides over all the scrum ceremonies and coaches the team to understand and implement scrum values and principals.
Product Owner – Is the Point of contact for a scrum team. He/she is the one who works closest to the business. The main responsibility of a product owner is to identify and refine the product backlog items.
Boost Meeting Productivity – Master Scrum Master Facilitation Techniques and guide your team to success.
Before the scrum sprint initiates, product owner reviews the list of all new features, change requests, enhancements and bug reports and determines the priority. If the project is new, it includes new features that the new system must provide- this list of the item is referred to as Product Backlog. The items that are kept on sprint are referred to as Sprint Backlog.
Velocity is a metric that is calculated by addition of all efforts estimates associated with user stories completed in one iteration. It predicts how much work Agile can complete in a sprint and how much time will it require to complete a project.
Tracer bullet can be used as a spike with the current architecture or the current set of best practices. The purpose of a tracer bullet is to examine how an end-to-end process will work and examine feasibility.
QA can provide value addition by thinking differently about the various scenarios to test a story. They can provide quick feedback to the developers whether new functionality is working fine or not.
QA is not a separate silo but is part of a cross-functional project team. It is included in the project from the beginning, and the whole team works together on user stories using the same tracking tools. The Director of the QA team works closely with the executive management team to identify technology and staffing needs in relation to project pipelines.
Quality Assurance is empowered to support projects and add value in whatever way the situation requires. Examples include design reviews, requirements assessments, browser and device support, process, tools, risk assessments, and helping to determine “Definition of Ready” and “Definition of Done.”
QA sits with the project team whenever possible, allowing for increased conversation and problem-solving in real time. The QA team attends and contributes to all relevant planning meetings and sprint ceremonies and also work directly with clients on quality and testing processes.
Members of QA teams always learn as individuals, as project team members, and as representatives of a skilled discipline within the organization. Our process and approach to testing evolve to keep up with advances in technology and the changing needs of clients. What works for one client or project might differ radically from another. Flexibility is the key.
Transform Your Legacy Systems – Start implementing Agile Mainframe Development for faster and more flexible solutions!
A scrum burndown chart should consist of:
X-axis that displays working days
Y-axis that displays remaining effort
Ideal effort as a guideline
Real progress of effort.
Scrum process artifacts include:
Sprint backlog – The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.
Product backlog – The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
Velocity chart– A velocity chart shows the sum of estimates of the work delivered across all iterations. Typically, velocity will stabilize through the life of a project unless the project team make-up varies widely or the length of the iteration changes.
Burn-down chart – It is a chart that shows how quickly you and your team are burning through your customer’s user stories. It shows the total effort against the amount of work we deliver on each iteration.
No, in an attempt to maximize velocity, a team may, in fact, achieve the opposite. If asked to maximize velocity, a team may skimp on the unit or acceptance testing, reduce customer collaboration, skip fixing bugs, minimize re-factoring. While potentially offering short-term improvement (if you can call it that), there will be a negative long-term impact. The goal is not to maximize velocity instead of the optimal velocity over time, which takes into account many factors including quality of the end product.
You can’t measure it easily. Velocity’s value comes from its inherent consistency. A fixed iteration length helps drive the reliable rhythm of a project. Without this rhythm, you are constantly revising, re-estimating, and reconciling, and the ability to predict out in the future is minimized due to inconsistent results.
If, on the other hand, almost everyone is going to be out a week for the holidays or a couple days for company-wide meetings then, by all means, adapt iteration dates or velocity accordingly. Like most agile practices, these are guidelines, not strict rules.
Impediments are the obstacles or issues faced by scrum team which slow down their speed of work. If something is trying to block the scrum team from their getting work “Done” then it is an impediment. Impediments can come in any form. Some of the impediments are given as –
Read More: To Share or Not To
Difference between Agile and Scrum – Agile is a broad spectrum, it is a methodology used for project management while Scrum is just a form of the Agile that describes the process and its steps more concisely. Agile is a practice whereas scrum is a procedure to pursue this practice.
The similarity between Agile and Scrum – The Agile involves completing projects in steps or incrementally. The Agile methodology is considered to be iterative in nature. Being a form of Agile, Scrum is same as that of the Agile. It is also incremental and iterative.
This is one of the commonly asked agile scrum interview questions and a quick answer can be given this way. An increment is the total of all the product backlogs items completed during a sprint. Each increment includes all the previous sprint increment values as it is cumulative. It must be in the available mode in the subsequent release as it is a step to reach your goal.
The build-breaker is a situation that arises when there is a bug in the software. Due to this sudden unexpected bug, compilation process stops or execution fails or a warning is generated. The responsibility of the tester is then to get the software back to the normal working stage removing the bug.
Scrum-ban is a Scrum and Kanban-based model for the software development. This model is specifically used for the projects that need continuous maintenance, have various programming errors or have some sudden changes. This model promotes the completion of a project in minimum time for a programming error or user story.
Some of the Agile quality strategies are –
This is the theory which most of agile/scrum roles aspirant should be on tips. Four manifesto values and 12 principles should be explained as much as possible as part of this question. Even if it’s not explained in 100% accurate manner it should be fine but intentions of values and principles should come out.
e.g.:
Yes, there are some drawbacks of the Agile model, some of them are as follows –
The burn-up chart illustrates the amount of completed work in a project whereas the burn-down chart depicts the amount of work remained to complete a project. Thus, the burn-up and burn-down charts are used to trace the progress of a project.
To answer this question, describe Zero Sprint and Agile in detail, as follows –
Zero sprint – Zero Sprint can be defined as the preparation step of the first sprint in Agile. There are some activities that are required to be done before actually starting the project. These activities are considered as the Zero sprint; the examples of such activities are – setting the environment for development, preparation of backlogs etc.
Spike – Spike is the type of story that can be taken between the sprints. Spikes are commonly used for the activities related to the design or technical issues such as research, design, prototyping, and exploration. There are two types of spikes – functional spikes and technical spikes.
Here’s how you can answer Scrum Master interview questions like this –
The scrum master is the leader as well as coach of the Scrum team. The scrum master is responsible to serve and protect his team from any kind of distractions that could affect their performance. The main role of the scrum master is to motivate his team to achieve the sprint goal. He is focused to build a self-organized and motivated team where each member is familiar with the implementation of Agile and Scrum principles and applications. The scrum master keeps a proper check on the scrum team if they are executing committed tasks properly. He is also responsible to increase the efficiency and productivity of the team so that they can achieve the sprint goal effectively.
Key responsibilities of a Scrum Master involve:
The three scrum roles i.e. Scrum Master, Product Owner and Team should be explained with the details of few primary responsibilities of each role. You can add more details as mentioned below for a particular depending on the role you are getting interviewed for.
Product owner – A product owner is actually the stakeholder of the project. He represents the project requirements before the team. He is responsible to have a vision of what to build and convey his detailed vision to the team. He is the starting point of an agile scrum software development project.
Scrum team – Scrum team is formed by the collective contribution of individuals who perform for the accomplishment of a particular project. The team is bound to work for the timely delivery of the requested product.
Scrum master – Scrum master is the leader and the coach for the scrum team who checks whether the scrum team is executing committed tasks properly. He is also responsible to increase the efficiency and productivity of the team so that they can achieve the sprint goal effectively.
Sashimi plays an important role in Scrum methodology. Sashimi is a technique used by Scrum to check the completion of all the functions created by the developers. Using this technique, all the requirements such as analysis, designing, coding, testing and documentation that are used in the constitution of a product are checked and only after that the product is displayed.
Agile testing is a software testing practice that is fully based on the agile principles of software development. It is an iterative methodology where the requirements are the outcome of collaboration between the product owner and team. The agile principles and applications are applied to meet the customer requirements by successful completion of the project.
An agile tester is one who implements agile software development principles for software testing. Followings are the skills of a good agile tester –
Scrum of scrum is used to refer the meeting after the daily scrum. The responsible person from each team attends the meeting and discuss their work and answer the questions like:
You may definitely come across agile scrum interview questions regarding agile matrices. The question may be related to a particular agile matric or explaining all the matrices. So, the detailed description of some common matrices for Agile is as follows:
Velocity – Velocity is the average number of points from last 3-4 sprints. It is measured by the summation of the all approved estimates of the stories. It gives an idea of the capacity, progress etc.
Cumulative Flow Diagram – With the help of cumulative flow diagram, an inspection is done over the uniform workflow. In this diagram/graph, the x-axis represents time whereas the y-axis represents the number of efforts.
Work Category Allocation – Work category allocation is an important factor that gives a quick information of the time investment i.e. where the time is being invested and which task should be given priority as a factor of time.
Time Coverage – It is the time that is given to a code during testing. It is calculated in percentage as a factor of the number of lines of code called by test suite and the total number of relative lines of code.
Business Value Delivered – It is a term which denotes the working efficiency of the team. The business objectives are assigned numerical values 1,2,3.. and so on, as per the level of priority, complexity, and ROI.
Defect Removal Awareness – It is the factor that helps the team to deliver a quality product. The identification of an active number of defects, their awareness, and removal plays an important role in delivering a high-quality product.
Defect Resolution Time – It is a procedure through which the team members detect the defects (bugs) and set a priority for the defect resolution. The procedure of fixing errors/bugs or defect resolution comprises of multiple processes such as clearing the picture of defect, schedule defect fixation, completing defect fixation, generation, and handling of resolution report.
Sprint Burn Down Matric – The sprint burndown chart is a graph to represent the number of non-implemented or implemented sprints during as Scrum cycle. This matric helps to track the work completed with the sprint.
Yes, sometimes it is suggested to use waterfall model over Scrum. It is done when the customer requirements are simple, well-defined, fully understood, predictable, and are not subjected to change until the completion of the project. It may the case that you would haven’t ever used waterfall over Scrum but you need to prepare for such Agile Scrum interview questions.
Scrum encourages the use of automated (automated performance or automated regression) testing to make the fastest possible delivery of the project. While answering this question, you may explain some tools that you have used for the automated testing.
Planning poker, also known as Scrum Poker, is a card-based agile technique that is used for planning and estimation. To start a session of planning poker technique, the agile user story is read by the product owner. The steps performed in the poker planning technique are –
54. Name some methodologies and development where you have used Agile model.
While answering this type of agile scrum interview questions, keep in mind to mention those methodologies that are familiar with. Some of the methodologies and development where Agile model can be used are –
This question is pure to judge your experience. The better you articulate your challenges working in agile better it will be. Challenges generally faced in the initial stages of scrum is stabilizing the velocity, team members conflicts, sticking to time-boxing etc.
56. Have you ever performed the removal of impediments as a scrum master on behalf of scrum team?
As the scrum master acts as a coach for his team, he should motivate his team to perform every task. Although he can remove impediments on behalf of scrum team but he should not do this. It is recommended for a scrum master not to over pamper nor overrule the team. There may be something when the team can face failure, at that time the scrum master should help them. He should guide them with an appropriate method t0 get out of the problem. Scrum master should prompt his team members to become independent enough to face problems and take a decision by themselves. This is one of the frequently asked scrum master interview questions, so prepare now and get ready to answer.
This question is to judge whether one is aware of the environment of the agile way of working. Here the answer is expected to cover few or all of below:
The difference between Sprint Planning Meeting and Sprint Retrospective Meeting is as follows:
Sprint Planning Meeting – A meeting in which all the Scrum roles (product owner, scrum team, and scrum master) have a discussion about the team’s priority features and product backlog items is known as sprint planning meeting. This meeting is held every week and lasts for almost 1 hour.
Sprint Retrospective Meeting – A meeting in which all the Scrum roles (product owner, scrum team, and scrum master) have a discussion about the good part of the sprint, the bad part of the sprint, and the sprint improvements is known as sprint retrospective meeting. This meeting that is held at the sprint review meeting or at the end of the sprint; it lasts for 2-3 hours.
This is one of the frequently asked Agile Scrum interview questions. You may be asked to define the above terms separately or the difference between these two.
Agile scrum interview questions may include a number of questions from agile testing. Let’s understand how you can answer such questions.
The agile testing methodology involves the division of whole testing process into multiple small segments of codes. In every step, these segments of codes undergo testing. There are a number of additional processes involved in agile testing methodologies such as team communication, strategic modifications for optimal results and many others.
Agile and scrum certifications are hot in market and organizations are expecting the candidates to hold one or more out of it. Certifications generally looked by organizations are:
If you have any of these certifications, showcase it here in a big manner. Due to many options available in the market, organizations also have started asking why you have chosen one. It’s recommended that for your certification you know few good points as its advantages handy with you so that it can be mentioned once asked.
This question may seem awkward to you but it is one of the most popular Agile Scrum interview questions. If an interviewer asks this question, it doesn’t mean that a certification is must for the job position. Just be confident while answering whether you have a scrum master certification or not. If you are a certified scrum master, just share the details of your certification like certification exam, score obtained, and the year of passing the certification exam. In case you don’t have a certification, mention and highlight your experience in the particular field. Also, let the interviewer know if you are planning to invest in the certification in the near future.
Here are some of the ways the Scrum team can have access to the stakeholders:
During scrum meeting,
Sashimi: This term is analogous to “done”, it is used to define the specific task when it is completed. The term used by different team to refer their completed task status may differ, but should remain same within one team.
Impediments: Any obstacle that prevent the team members from performing their work is referred as impediments.
Burn down charts is used to track sprint status, they act as an early warning indicator, they can be useful in highlighting the “lack of progress”. Also, they will highlight the area where they see redundancy.
The objective behind Sprint retrospective meeting is to let team members know how things went during the sprint and discuss possible ways for further improvements for future sprints.
Iteration: It is a terminology used to define single development cycle in general agile methods. It is a common term used in the iterative and Incremental development process.
Sprint: It is used to define one development cycle or iterative step in a specialized agile method referred as Scrum. Sprint is scrum specific, and not all forms of iterations are Sprints.
Each feature in scrum is Story. Story point is an arbitrary measure used by Scrum teams, and it is a metric used by agile teams to determine the difficulty of implementing a given story.
Ideally scrum is useful to monitor work with 5 to 10 people, who are committed to achieving the sprint goal. It does not go well with huge groups or team having more responsibilities. For larger team, scrum can be applied by splitting the team into small groups and practice scrum.
A Scrum Master does not wield any real authority; the scrum team does not report to them. This question, therefore, is meant to discern whether the candidate understands that their role is to lead — as opposed to manage — the team. This question should also help to discern why a candidate is interested in the role of a Scrum Master in the first place. Acceptable answers include:
This question is, in part, a subset of the previous question. However, and especially when concerning the change management process itself, there are effects that could be measured with a scoring model. Some of these effects are:
Usually — before introducing an agile framework within an organization — it is useful to gather the status quo (the baseline) of these dimensions and review their evolution through time.
These metrics should be continuously addressed throughout the agile journey (via surveys with team members in agile departments, for example).
This question addresses various issues. There are many possible factors that might combine to make a team’s velocity volatile. Such factors might include:
If the team’s commitment is frequently too aggressive, this could indicate that user stories are poorly prepared — e.g. the definition of ready is not met — which makes the stories hard to estimate. Conversely, their projects might suffer from poorly documented legacy code, excessive technical debt, or just too much buggy and poorly written code — all of which make estimation very hard.
Organizations must be vigilant and not fall for the fallacy that agile is working because commitment and velocity are aligned. Cooking the agile books is easy to do!
There are various ways of engaging stakeholders with scrum:
This is a deliberately open question meant to encourage discussion. The candidate should be concerned with how to spread an agile mindset throughout an organization, or, more particularly, how to create a learning organization that embraces experimentation in order to identify the best product for its customers.
This is another open question, meant to encourage an exchange of ideas about and lessons learned when overcoming resistance to agile within an organization. Familiarity with agile failure patterns common in many organizations will demonstrate a candidate's experience — we have published a list of agile failure patterns at Age of Product.
A Scrum Master should not accept such a procedure, as it’s nothing more than a waterfall process dressed-up in a pseudo-agile methodology. If the entire organization is supposed to focus on delivering value to its customers, it is essential that any process involving “requirements” being handed down to the engineers by a JIRA monkey be abandoned. Instead, the organization should start including everyone in the product discovery process — thereby establishing a shared understanding of what needs to be built.
Any information suitable to provide the team, with an understanding why something is of value to customers. This may be of a quantitative nature, e.g. analytical data describing how a process is utilized. It also may be of a qualitative nature, such as transcripts, screencasts, or videos from a user testing session.
A good user story:
A “Definition of Ready” is an agreement between the scrum team and the product owner about what must be included in a user story before the story can be considered ready for estimation. It defines what a good user story looks like. Another approach, however, is to use a framework for how we think about user stories. One such framework is the INVEST mnemonic by Bill Wake, which specifies:
Independent: The user story should be self-contained, in a way that there is no inherent dependency on another user story.
Negotiable: User stories, until they become part of an iteration, can always be changed and rewritten. Valuable: A user story must deliver value to the end user.
Estimable: You must always be able to estimate the size of a user story.
Small: User stories should not be so big as to become impossible to plan, task, and prioritize with a certain level of certainty.
Testable: The user story or its related description must provide the necessary information to make test development possible.
It's okay to use hours instead of points when the team and the organization can deal with it. However, some organizations will fall back into waterfall planning when work is estimated in hours.
Estimating in hours might also be tricky when:
Story points are more suitable in these situations because the points more accurately reflect both required effort and complexity. This is a result of points being used not only for estimation, but also as a means to measure and convey commitments and team velocity.
Any product backlog larger than the scope of two or three sprints is not manageable. Misusing a backlog by adding hundreds of items to it is a clear sign that the product owner needs help from the team to cope with the influx of ideas, suggestions, and requirements — and avoid misallocating resources. This support is what the candidate should offer.
The scrum team should never select user stories according to any kind of ranking established by the product owner or anyone else. Sprint planning is determining the most efficient path to value creation. The best way to accomplish this is to ensure that:
If a team is involved early enough in the process, for example by jointly creating user stories with the product owner, or during product discovery, any kind of guidance will be unnecessary. Most teams will often autonomously pick the best user stories for a given sprint. If a team resorts to “cherry picking” user stories during sprint planning, however, then the backlog refinement process needs to be seriously addressed, as the product owner is likely picking user stories that are not maximizing customer value.
Setting aside the most critical and urgent tasks (such as the web site being offline), the 15–10–5 approach is generally a good rule of thumb: dedicate 15% of a team’s capacity to technical debt, 10% to bugs, and 5% to explorative spikes. You may, of course, deviate from this when it comes to an individual sprint. But, generally, maintaining these allocations will satisfy the maintenance requirements of most software applications.
Assigning tasks to individual team members does not work at all and needs to be stopped. The assignment of user stories is the scrum team’s prerogative. Preventing individual task assignment, if likely to occur, should be one of the Scrum Master’s most pressing concerns.
A scrum team should generally have autonomy in how its members choose to distribute tasks. Maybe the presumed “cherry picking” of tasks by individual team members is a crucial part of the team’s path to performance.
However, if team members complain about this happening, the scrum master needs to address the issue. Additional training might enable some team members to accommodate a greater variety of tasks. Or, perhaps, someone needs to be gently pushed out of their comfort zone so that they learn to choose different kinds of tasks than the kinds they currently choose.
The answer to this depends upon the team’s situation and experience: If the design department will definitely deliver (because they have done so in the past); if the user story is high value and can be accomplished within the sprint despite its UI deliverables arriving late; and if the team agrees — it’s probably an acceptable exception.
Beware, however, that this kind of exception does not become the “new normal” — allowing the organization to bypass the backlog refinement and sprint planning process. The candidate should be aware that such a situation would not be tenable.
Furthermore, if implementation of a user story subjected to such an exception fails, no one will bother to read the fine print and acknowledge that an exception had been made; instead, they will most likely view the agile process itself as having failed.
Candidates may either accept or reject exceptions to the agile process, but they should be able to analyse the situation and explain the collateral damage that the scrum team may be exposed to.
This kind of passive–aggressive behaviour is not necessarily a problem particular to scrum. It is, however, toxic, and will affect both team-building and performance. If a member of a scrum team is behaving in this way, the Scrum Master will need to take action, as such behaviour can neither be ignored nor tolerated if the team is to continue functioning. Dealing with it may require an escalating approach:
In answering this question, the candidate should exhibit common sense. Standups are an important part of scrum, but not all standups need to be formal. A small, experienced, collocated team may use a coffee break for their standup. However, taking that kind of relaxed approach to standups for a large team with several junior members would probably achieve nothing if it doesn't first descend into chaos. For large teams, a formal meeting is needed to provide format and guidance. For distributed teams who need to “dial in” and, for obvious reasons, can't meet for coffee, a formal standup is necessary insofar as the standup, due to technical constraints, must be scheduled and conducted in an organized fashion.
Certainly not. Waiting for the next standup delays progress. When facing impediments, if team members are waiting for the next standup before asking for help, it's likely that the “team” is more of a group — and the scrum master has team-building work to do.
All teams go through Tuckman’s stages of group development: norming, storming, forming, performing. Scrum teams included.
Although there are not officially any leadership roles within a scrum team, someone is likely to assume that role. This might happen because of his or her (technical) expertise, communication skills, or level of engagement. It’s important, however, that this does not result in other team members reporting to this person. The Scrum Master must therefore be vigilant and intervene if necessary to ensure team members communicate — during standups or otherwise — as required by scrum.
The kind of passive–aggressive behaviour depicted by this question is not necessarily a problem particular to scrum. It is, however, toxic, and will affect both teambuilding and performance. If a member of a scrum team is exhibiting such an attitude, the scrum master will need to take action. Such behaviour can neither be ignored nor tolerated if the team is to continue functioning. Dealing with it may require an escalating approach:
This can quickly turn into a philosophical discussion. Should stakeholders be allowed to participate in daily scrums? If they do, is it a form of reporting — circumventing scrum rules?
If some adaptation of scrum is working in your organization — that’s a good thing.
Don’t rule out stakeholders being allowed to participate in the daily standups if the team is okay with that. In fact, if stakeholders attend standups regularly, this will invariably and significantly improve communication between the team and the stakeholders — another good thing.
But how does a Scrum Master encourage stakeholders to attend standups? Make it worth their while. A Scrum Master can do this in any number of ways. They might offer stakeholders the opportunity to learn early details of a new product or feature if they attend. They might also choose to give stakeholders the opportunity to ask questions of the engineers directly, without going through the product owner.
Standups with distributed teams are not much different to standups with colocated teams — except that sharing board activity may require video conferencing when the team is working with offline boards that mirror each other.
If you are using task management or planning software like JIRA (or any other cloud-based application), board updates are generally easy for each team member to follow on-screen. With such online software in place, a Skype call or Google Hangout may suffice.
The qualifier “kanban” is, of course, a teaser. But any Scrum Master should be able to draw a simple board. The necessary elements of any board are columns (or rows) for:
Additional information may be included on or attached to any kind of board:
Although not mandatory, it's generally best practice to include the product owner in retrospectives — they are an important part of the “team”, both practically and functionally. Some scrum teams, however, may not always want their product owners to participate — a team’s wishes should be considered. Anyone else outside of the immediate scrum team, and particularly managers of team members, should not be invited to participate.
Measuring a team’s health is a good way to get an idea about current levels of engagement and satisfaction and is a useful method for discerning trends. A simple scale from 1 (terrible) through 2 (poor), 3 (neutral), 4 (good), to 5 (excellent) will do the job — and requires just two minutes to complete.
With retrospectives, one size does not fit all. Consequently, there are various retrospective formats in common use:
The classic format:
The boat format:
The starfish retrospective:
Each serves different situations. The candidate should have applied more than one of these formats in the past and be able to share their reasons for having done so.
Any of numerous possible variations may be used to prevent boredom during retrospectives. A different location; a different format; shortening or lengthening the allotted time box. Scrum masters can also use the team’s choice of action items to encourage and structure discussions around the issues that the team themselves thus identified — creating engagement through acknowledgement.
There is no single correct answer to this question. What’s important is that the candidate acknowledges that boredom might become an issue, and that there are ways to deal with it.
If action items are picked but no one is later delivering on their commitments, the Scrum Master needs to follow up.
If this is happening because of some impediment external to the team, the Scrum Master needs to address and eliminate the cause. The team can then catch up during a later sprint.
However, if there is no external impediment, the problem is likely due to motivation, attitude, or personal issues within the team. In this latter case, the Scrum Master needs to provide those team members responsible with the encouragement or motivation necessary to overcome the problem and see that they deliver on their commitments.
If the problem cannot ultimately be resolved, picking action items becomes a useless exercise — and the team will suffer as a result.
A good follow-up practice is to start talking about the status of the action items of the last retrospective — before picking new ones. If actions item from the last retrospective haven’t been accomplished, the scrum team needs to understand why they failed and prevent that failure from happening again.
It’s measured by Velocity.
Neither the scrum master, not the product owner. It’s the responsibility of the team who owns the deliverable.
Complexity and effort is measured through “Story Points”. In scrum it’s recommended to use Fibonacci series to represent it.
The progress is tracked by a “Burn-Down chart”.
During Sprint review we walkthrough and demonstrate the feature or story implemented by the scrum team to the stake holders.
During retrospective, we try to identify in a collaborative way what went well, what could be done better and action items to have continuous improvement.
I don’t see any disadvantage of using scrum. The problems mainly arise when the scrum team do not either understand the values and principles of scrum or are not flexible enough to change.
Scrum is used mainly for:
First thing we will not mark the story as done.
We will first confirm the actual requirement from the stakeholder and update the user story and put it into backlog. Based on the priority, we would be pulling the story in next sprint.
Yes, we can very well go ahead and do our daily stand up meeting.
Automation plays a vital role in Scrum. In order to have continuous feedback and ensure a quality deliverable we should try to implement TDD, BDD and ATDD approach during our development. Automation in scrum is not only related to testing but it is for all aspect of software development. As I said before introducing TDD, BDD and ATDD will speed up our development process along with maintaining the quality standards; automating the build and deployment process will also speed up the feature availability in different environment – QA to production. As far as testing is concerned, regression testing should be the one that will have most attention. With progress of every sprint, the regression suit keeps on increasing and it becomes practically very challenging to execute the regression suit manually for every sprint. Because we have the sprint duration of 2 – 4 weeks, automating it would be imperial.
We have the Product backlog refinement meeting (backlog grooming meeting) where the team, scrum master and product owner meets to understand the business requirements, splits it into user stories, and estimating it.
Scrum can be implemented in all kinds of projects. It is not only applicable to software but is also implemented successfully in mechanical and engineering projects.
The major advantage which I feel is – Early feedback and producing the Minimal Viable Product to the stakeholders.
DoD stands for Definition of done. It is achieved when the story is development complete, QA complete, the story meets and satisfy the acceptance criteria regression around the story is complete the feature is eligible to be shipped / deployed in production.
A Minimum Viable Product is a product which has just the bare minimum required feature which can be demonstrated to the stakeholders and is eligible to be shipped to production.
Epics are equivocal user stories or we can say these are the user stories which are not defined and are kept for future sprints.
A Story point is calculated by taking into the consideration the development effort+ testing effort + resolving dependencies and other factors that would require to complete a story.
Yes, this is a very common scenario. There may be a chance that the story point given by the development team is, say 3 but the tester gives it 5. In that case both the developer and tester have to justify their story point, have discussion in the meeting and collaborate to conclude a common story point.
In ideal case, the requirement becomes a story and moves to the backlog. Then based on the priority, team can take it up in the next sprint. But if the priority of the requirement is really high, then the team will have to accommodate it in the sprint but it has to very well communicated to the stakeholder that incorporating a story in the middle of the sprint may result in spilling over few stories to the next sprint.
A story is done only when it is development complete + QA complete + acceptance criteria is met + it is eligible to be shipped into production. In this case if there are defects, the story is partially done and not completely done, so I will spill it over to next sprint.
Characteristics of Dev Team in Scrum are as follows:
It is a type of agile software development. It advocates frequent releases in short development cycles, which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to extreme levels. XP addresses the analysis, development, and test phases with novel approaches that make a substantial difference to the quality of the end-product. It is a type of agile software development. It advocates frequent releases in short development cycles, which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to extreme levels. XP addresses the analysis, development, and test phases with novel approaches that make a substantial difference to the quality of the end-product.
Below give few key differences between Agile and Waterfall
The keyword over in all these manifesto statements. Manifesto is not suggesting to replace the items in right with left rather it stress upon prioritizing left items over right.
Below are few key advantages of Agile over waterfall
Few indications are
129. How is scrum different from other Iterative models?
Scrum is not just an iterative model but it is an iterative model with incremental progress. Other Agile methodology include – KanBan, XP, Lean, FDD etc.
Iteration: It is a terminology used to define single development cycle in general agile methods. It is a common term used in the iterative and Incremental development process.
Sprint: It is used to define one development cycle or iterative step in a specialized agile method referred as Scrum. Sprint is scrum specific, and not all forms of iterations are Sprints.
It depends on the size and coupling between those teams, and there are various frameworks for it –
• SAFe – Scaled Agile Framework
• LeSS – Large Scale Scrum
• SoS – Scrum of Scrum.
professionals trained
countries
sucess rate
>4.5 ratings in Google
05 Jul 2019
15 mins
