Types of Agile Methodologies

Agile Software development is a High-Level Term used for all different kinds of incremental and iterative software development frameworks and these frameworks essentially follow the core ideas of Agile development like the 12 point agile manifesto. Some of the most widely used frameworks in the industry which are considered the various types of agile methodologies are:

  • Scrum
  • Extreme Programming (XP)
  • Kanban
  • Lean
  • SAFe (Scaled Agile Framework)
  • TDD (Test Driven Development)
  • ATDD (Advanced Test Driven Development)

These frameworks differ from each other in several ways but the basic values of all of these are derived from Agile Manifesto. All these are iterative and incremental processes which support the idea of continuous improvement. In other words, all these frameworks prescribe to develop the final product in small batches and eventually deliver it as a whole on time and on budget. Also keep improving the process continuously inspecting and adapting to the changes on the fly. And the above listed frameworks also emphasize on the empowerment  and self organization of the team members.

 

Like my blog? 

 

Scrum Master Interview Questions

Below are some of the basic Scrum Master Interview Questions to get you prepared for your next one:

What is a daily scrum Meeting?

Ans: It’s a daily 15 minute meeting where the team comes together and every individual on the team (except the ScrumMaster and Product owner) talks about 3 below listed items:
– What they last yesterday?
– What are they going to work on today?
– Any blockers they have?

 

What are the most important scrum artifacts? And who maintains them?

Ans: Below is the list:
– Product Backlog   (Maintained by the product owner)
– Release Backlog   (Maintained by the product owner)
– Sprint Backlog   (Maintained by the team)
– Sprint Burn down   (Maintained by the ScrumMaster)
– Release BurnUp   (Maintained by the ScrumMaster)

 

What type scrum ceremonies have you conducted in the past?

Ans: Below is the list:
– Daily Scrums
– User Story Grooming Meetings
– Sprint Reviews
– Retrospectives
– Sprint Planning
– Release Planning

 

What does a scrum team look like?

Ans: An ideal scrum team consists of:
– 1 scrum master
– 1 product owner
– 5±2 cross functional team members (who can develop and test)

But in real world since its difficult to find cross functional team members, most teams have:
– 1 Scrum master
– 1 product owner
– 3±2 Devs
– 3±2 testers.

 

What are the different agile management tools available in the market?

Ans: Below is the list of most popular Agile management tools:
– 1 Scrum master
– Rally
– TFS (Team Foundation Server)
– RTC (Rational Team Concert)

 

What is the difference between a Sprint and an Iteration?

Ans: Sprint and iteration are one and the same thing. No difference at all.

 

What is the difference between a Product Owner and a ScrumMaster?

Ans: Please refer to – Product Owner and Scrum Master

 

What is a scrum board?

Ans: Its a board which lists all the user stories and defects in the current sprint with their current statuses. It contains different columns like:
– In Analysis
– In Dev
– In QA
– Done!
Scrum Board can be a physical board or a virtual board in one of the agile management tools like JIRA, Rally etc.
One scrum board per team.

 

Why scrum framework prescribes Dev team members to be cross functional?

Ans: Since scrum prescribes to run all the activities (Analysis, Dev, QA, UAT, deployment) in parallel for individual user stories within a sprint, its best to have cross-functional team members who can Develop and test.

 

Difference between Epics, User stories and tasks?

Ans: Epic – is a high level requirement which can be broken down into smaller workable pieces to fit within an iteration. An epic contains several User stories.
User Stories – are the requirements which are broken down to such a small level that they can be completed in one iteration. A User Story can contain several tasks.
Tasks – A task details out what needs to be done to complete a user story. Like There can be Dev tasks, QA tasks, Analysis tasks etc. Every task has estimated number of hours (to complete that task) attached to it. So the total number of hours on all the tasks for a user story can give the estimation of how long it will take to complete that user story.

 

What is Velocity?

Ans: The total points for the number of stories marked done in a sprint/iteration of a team are considered as the velocity of that team for that specific iteration.

 

How is Average Velocity calculated?

Ans:Typically we take velocity of past 3 iterations and calculate the average velocity by using the following method:
Average Velocity = V1 + V2 + V3 / 3
V1= Velocity of sprint 1
V2= Velocity of sprint 2
V3= Velocity of sprint 3

 

What has been the average velocity of your past teams?

Ans: Velocity differs from team to team so its very specific to your past experience.

 

What was the highest and lowest Story points you used in your past projects?

Ans: The lowest typically can be ‘0’ or ‘0.5’ but the highest totally depends on your team. Use your past experience to answer this.

 

How can you standardize the velocity across all teams in an organization?

Ans: Standardizing the velocity across all teams may not work out very well as different teams work on different type of work and they may not have enough similarities in their work to standardize the story pointing. Also we must not forget points that different teams may have different velocities based on the way they point their stories but that doesn’t not necessarily mean that team with higher velocity is performing better than the team with lower velocity.

 

How can you know the velocity of a newly setup team and how to plan work for that team’s coming iterations?

Ans: Teams commit to an amount of work for a sprint/iteration based on their average velocity. But a new team doesn’t have a set average velocity so for the first sprint they go by the gut feel of the team.
Based on the team members past experience they can tell how much work they can accomplish in a sprint and after pulling that much work in the first sprint they will have to see if that much work was more for them or lesser and based on that experience they choose the amount of work for next sprint and so on.
These learning are discussed in the team retrospectives.

 

What is a product increment?

Ans: Product increments are the pieces of functionalities that are completed in individual sprints/iterations and added to the product itself.

 

What is the difference between a BurnUp and a BurnDown?

Ans: BurnUp – It represents story points adding up to the total scope on a graph and it is typically used for showing Release progress (called Release BurnUps)

BurnDown – In contrary to a burn ups it represents a graph of story points starting from the actual scope and burning down to ideally 0 as the days in a sprint go by. Typically used for Sprints (called Sprint Burn Downs)

 

How do you quantify work in Agile?

Ans: Work is quantified using ‘Story Points’. Every story carries story points and the total effort in a sprint or in a release is the total number of story points on the stories in that specific sprint or Release.

 

How do you estimate work in Agile?

Ans: Several estimation techniques are available in the industry but the most popular and in my opinion the most effective is Planning Poker technique. Almost all agile teams in the industry use this technique.

 

What is Planning Poker and how to conduct it?

 

Who writes the stories and who marks them Done ?

Ans: Any team member can write stories and add them to the product backlog but those need to be well defined and estimated before they get pulled into an actual sprint / iteration.

The typical route of closing stories is that a tester passes the stories after testing and demos them to the Product Owner to mark them Done/Accepted.

 

What is the difference between product backlog and sprint backlog?

Ans: Product Backlog – All the planned and unplanned work, in the form of user stories, for a product is maintained in the product backlog. Stories in the product backlog may not be ready to be played since they may lack Acceptance Criteria or final estimates.

Sprint Backlog – The list of stories in a sprint is called sprint backlog. Its a subset of product backlog stories but all the stories pulled into a sprint are well defined and estimated.

 

How can you help your team continuously improve?

Ans: Retrospective meetings provide an excellent opportunity to introspect and find out what are the areas of improvement. Team should make use of this ceremony to continuously improve.

 

If your committed work doesn’t get completed in a sprint, do you increase the length of that sprint?

Ans: No the time box always stays the same, the remaining work moves over to the next sprint/iteration.

 

What is a sprint goal? and who sets it?

Ans: Sprint goal is a short term goal set to be accomplished within a sprint. Each sprint can have a different sprint goal. For example: Team X is going to complete all the stories related to a certain functionality.

Team should set a sprint goal for themselves not the scrum master nor the product owner.

 

What is an Acceptance Criteria?

Ans: The list of functionalities/micro-functionalities to be developed are listed in a user story and that list is called the Acceptance Criteria for that story and it also describes what needs to be developed and tested to mark that story done.

 

Who writes Acceptance Criteria in the user stories?

Ans: Product Owner writes the acceptance criteria for every single story.

 

What happens if a user story contains 4 acceptance criteria but developer ends up developing only 3 and misses the 4th?

Ans: A user story does not get accepted until the all the ACs in a user story are developed and tested.

 

What is Definition of Ready?

Ans: A list of criteria set to determine if a user story is ready to be pulled into a sprint and can be worked on. For example:
– User story is defined
– User story is sized

 

Similarly what is Definition of Done?

Ans: A list of criteria set to determine if a user story can be marked Done. For example:
– Code produced
– Tested
– Passed UAT
– Deployed

 

How do you plan for releases?

 

Like my blog?