Basic Agile Scrum Interview QA

AGILE

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. Agile methods or Agile processes generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. Agile development refers to any development process that is aligned with the concepts of the Agile Manifesto. The Manifesto was developed by a group fourteen leading figures in the software industry, and reflects their experience of what approaches do and do not work for software development. Read more about the Agile Manifesto.

SCRUM

Scrum is a subset of Agile. It is a lightweight process framework for agile development, and the most widely-used one.

• A “process framework” is a particular set of practices that must be followed in order for a process to be consistent with the framework. (For example, the Scrum process framework requires the use of development cycles called Sprints, the XP framework requires pair programming, and so forth.)
• “Lightweight” means that the overhead of the process is kept as small as possible, to maximize the amount of productive time available for getting useful work done.

A Scrum process is distinguished from other agile processes by specific concepts and practices, divided into the three categories of Roles, Artifacts, and Time Boxes. These and other terms used in Scrum are defined below. Scrum is most often used to manage complex software and product development, using iterative and incremental practices. Scrum significantly increases productivity and reduces time to benefits relative to classic “waterfall” processes. Scrum processes enable organizations to adjust smoothly to rapidly-changing requirements, and produce a product that meets evolving business goals. An agile Scrum process benefits the organization by helping it to

• Increase the quality of the deliverables
• Cope better with change (and expect the changes)
• Provide better estimates while spending less time creating them
• Be more in control of the project schedule and state

1. What is the duration of a scrum sprint?

Answer: Generally, the duration of a scrum sprint (scrum cycle) depends upon the size of project and team working on it. The team size may vary from 3-9 members. In general, a scrum script complete in 3-4 weeks. Thus, on an average, the duration of a scrum sprint (scrum cycle) is 4 weeks. This type of sprint-based Agile scrum interview questions is very common in an agile or scrum master interview.

2. What is Velocity?

Answer: Velocity question is generally posed to understand if you have done some real work and familiar with the term. Its definition “Velocity is the rate at which team progresses print by sprint” should be enough. You can also add saying the important feature of velocity that it can’t be compared to two different scrum teams.

3. What do you know about impediments in Scrum? Give some examples of impediments.

Answer: 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 –

• Resource missing or sick team member
• Technical, operational, organizational problems
• Lack of management supportive system
• Business problems
• External issues such as weather, war etc
• Lack of skill or knowledge

While answering impediments related agile scrum interview questions remember that you may be asked the way to remove any of the mentioned impediment.

4. What is the difference and similarity between Agile and Scrum?

Answer: 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.

5. What is increment? Explain.

Answer: 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.

6. What is the “build-breaker”?

Answer: 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.

7. What do you understand by Daily Stand-Up?

Answer: You may surely get an interview question about daily stand-up. So, what should be the answer to this question? The daily stand-up is an everyday meeting (most preferably held in the morning) in which the whole team meets for almost 15 minutes to find answer to the following three questions –

• What was done yesterday?
• What is your plan for today?
• Is there any impediment or block that restricts you from completing your task?

The daily stand-up is an effective way to motivate the team and make them set a goal for the day.

8. What do you know about Scrum ban?

Answer: 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.

Measurements in Agile

A burndown chart shows the amount of work that has been completed in an epic or sprint, and the total work remaining. 

Burndown charts are used to predict your team's likelihood of completing their work in the time available. They're also great for keeping the team aware of any scope creep that occurs.

Burndown charts are useful because they provide insight into how the team works. For example:

If you notice that the team consistently finishes work early, this might be a sign that they aren't committing to enough work during sprint planning.
 
If they consistently miss their forecast, this might be a sign that they've committed to too much work.

If the burndown chart shows a sharp drop during the sprint, this might be a sign that work has not been estimated accurately, or broken down properly.

The estimation statistic is the unit of measurement your team will use to estimate work. You can measure work using story points, hours, or you can come up with your own statistic.

Sprint burndown chart

This report shows the amount of work to be done in a sprint. It can be used to track the total work remaining in the sprint, and to project the likelihood of achieving the sprint goal. 

1. Estimation statistic: The vertical axis represents the estimation statistic that you've selected.
2. Remaining values: The red line represents the total amount of work left in the sprint, according to your team's estimates.
3. Guideline: The grey line shows an approximation of where your team should be, assuming linear progress. If the red line is below this line, congratulations - your team's on track to completing all their work by the end of the sprint. This isn't foolproof though; it's just another piece of information to use while monitoring team progress

Epic burndown chart

This report shows you how your team is progressing against the work for an epic.

1. Epic menu: Select which epic to view data for.
2. Work added: The dark blue segment shows the amount of work added to the epic in each sprint. In this example, work is measured in story points.
3. Work remaining: The light blue segment shows the amount of work remaining in the epic.
4. Work completed: The green segment represents how much work is completed for the epic in each sprint.
5. Projected completion: The report projects how many sprints it will take to complete the epic, based on the team's velocity.

Velocity Chart

The Velocity Chart shows the amount of value delivered in each sprint, enabling you to predict the amount of work the team can get done in future sprints. It is useful during your sprint planning meetings, to help you decide how much work you can feasibly commit to.

1. Estimation statistic: The y-axis displays the statistic used for estimating stories. In the example above, the team is using story points. Estimates can also be based on business value, hours, issue count, or any numeric field of your choice. 
2. Commitment: The gray bar for each sprint shows the total estimate of all issues in the sprint when it begins. After the sprint has started, any stories added to the sprint, or any changes made to estimates, will not be included in this total. 
3. Completed: The green bar in each sprint shows the total completed estimates when the sprint ends. Any scope changes made after the sprint started are included in this total.
4. Sprints: The x-axis displays the last 7 sprints completed by the team. This data is used to calculate velocity. 

Velocity is calculated by taking the average of the total completed estimates over the last several sprints. So in the chart above, the team's velocity is (17.5 + 13.5 + 38.5 + 18 + 33 + 28) / 6 = 24.75 (we've ignored the zero story point sprint). This means that the team can be expected to complete around 24.75 story points worth of work in the next sprint.

Cumulative Flow Chart

A Cumulative Flow Diagram (CFD) is an area chart that shows the various statuses of work items for a product, version, or sprint. The horizontal x-axis in a CFD indicates time, and the vertical y-axis indicates cards (issues). Each coloured area of the chart equates to a workflow status (i.e. a column on your board).

Work in Process or Work in Progress (WIP)

Tracking work items that are started, but not yet finished, can help you improve the overall flow of value through the system. 

Practically speaking, work cannot add value to the customer, team, or organization unless it’s finished work

Lead Time and Cycle Time

Lead time and cycle time are two useful metrics for understanding how long work takes to flow through your Kanban system. 

Lead time tracks the total amount of time it takes from when work is requested until it's delivered. 

While cycle time tracks the amount of time we spend working on it while it's on our board.

Throughput

Throughput is the average number of units processed per time unit. 

In a Kanban system, examples can include “cards per day,” “cards per week,” or “story points per iteration.”

Kaizen is a Japanese word that literally translates to change for the better. 

It's a fundamental part of lean methodology.

Improvement Cada 

If you're a leader in your organization, you should allow individuals on your team to suggest issues or identify waste as and when they see it. - That's right. 

An organization cannot self-improve unless the people who are part of it are comfortable talking about inefficiencies and waste.

 Gemba, the real place where our work is done. It could be chat, our ticket tracker, or search control system.
Not being in touch with the gemba make you unable to make good decisions as a leader.

A Lean adoption requires changing mindsets. Pulling instead of pushing and delivering the minimum, and then iterating based on feedback are very different for how many organizations work on both explicit and implicit levels. In terms of specific DevOps practices, it's continuous delivery. To adopt Agile, and Lean, and DevOps it requires people to learn new skills.That takes some work, but it's not the hard part. It's changing the culture and way of working that's hardest.

The empowerment and respect for employees that a real Lean and Agile implementation brings, is a major game changer, not just to business outcomes but to the quality of life of the teams involved.

Agile Software Development

Agile Software Development manages and develops software in an iterative and incremental way.

The four important values that guide the principles of Agile Development are

a.Individuals and interactions over tools and processes

b.Working software over comprehensive documentation

c.Customer collaboration over contract negotiation

d.Responding to change over following a plan. 

In Agile development the process is deliberately more iterative. - Right, instead of trying to complete each phase up front it stresses flexible collaboration between both workers and customers around frequent inner room deliverables of working software. This can quickly generate solutions that better address customer needs with fewer lingering quality problems.

12 Principles of Agile are,

What are the benefits for Organisations ?

From a business perspective, the two biggest wins are visibility and the continuous delivery of business value. Because product owners are a part of the team building the software, they can visualize the progress towards a working product through every iteration. 

If necessary, they can make changes from iteration to iteration. From a business perspective, owners always know how the project is progressing. - That's right.

In a traditional waterfall development cycle, the communication between product owners and development happens frequently at the start of the project but declines as the project progresses. - In later stages, when the product owner does get an update and requests changes, these can be really difficult to make. From a dev teams perspective, it changes the scope and affects the product timeline. This can understandably cause friction between the owners and the developers. - An Agile approach is deliberately more iterative. You deliver working software from the very beginning.

Another key differentiator of Agile is communication. Frequent communication between the team members and with external stakeholders during the entire project lifecycle allows the whole team to be more adaptable. - The development team can anticipate upcoming changes in scope.Product owners can see iterative progress. And test and deployment teams are aware of what's coming up and can be prepared. - Finally because the entire team is working in sync, the overall status and risk of the project is known in a manner that's impossible in traditional development processes. The developers on the team can raise concerns about complexity or issues with specific features to the product owners during the implementation phase, giving them the chance to revisit workflow and requirements. The added communication reduces risk and gives everyone further visibility into where features actually stand.

These include Extreme Programming, called XP for short, Scrum, Kanban, Dynamic Systems Development Method, Feature Driven Development, Lean, Scrumban, Rational Unified Process, also known as RUP for short and a few others. Artifacts are deliverables, activities or units of work and workflow.

RUP ( Rational Unified Process) is an entire framework that covers whole areas of the development process from business modeling through deployment and has deliverables for each phase in addition to well defined handoffs.

Scrum comes from a rugby term and refers to a tight player formation that's trying to move the ball towards the goal.

This is the Scrum life cycle. Every project has a product backlog which is a prioritized set of desired product features.The highest priority items are selected and implemented in a two to four week period in the sprint iteration.

In the Scrum framework, a sprint is simply a time box of a month or less. Everyday there's a quick, daily meeting called a standup where three topics are covered. 

1. What was covered since the last meeting? 
2. What is the intended task for the day, and are there any impediments? 
3. At the end of an iteration, progress is demonstrated in a sprint review meeting followed by retrospective.

Any tasks that weren't completed either get rolled to the next sprint or re-prioritized in the backlog. There are three specific roles in Scrum. 

First, the product owner who represents the customers and stakeholders. They're accountable for developing features that are important to the business. They're also the primary controllers for the Scrum backlog and prioritize tasks on the boards and set sprint goals. 

The development team is a cross-functional team responsible for actually doing the work and shipping iterations of the product.

And finally, the Scrum master facilities the Scrum process and makes sure that the progress is happening as expected. He or she makes sure that the team is not blocked and helps unblock the development team as needed. 

Unlike Scrum, Kanban focuses on delivery and not overloading developers. 

Taiichi Ohno, who was an industrial engineer at Toyota, developed the Kanban methodology to improve efficiency at the manufacturing plant.

Like Scrum, Kanban also has a prioritized backlog. Often, there might be a ready column from which developers pick up tasks followed by a doing column which symbolizes that a task in progress followed by a done column that signifies that a task is complete. Often on a Kanban board, you'll see a number on the column.

Scrum is based on time box sprints where work can be pulled through in batches and no changes are allowed during the iteration. 

Kanban fits great when there's a high degree of change and variability where Scrum fits better in a situation where work can be prioritized and time boxed. 

Lean Technologies 

Lean started in the manufacturing world. - Lean was devised by a combination of innovators including W. Edwards Deming and Taiichi Ohno

Lean is also inspired by statistical process control (SPC) and its focus on continuous improvement in designed experimentation. And it inherits from Henry Ford's original work in Just In Time (JIT) manufacturing.  

Lean is a systematic method to eliminate waste and maximize the flow of value through a system. Value is defined as something your customer will pay money for. 

Lean employs something called value stream mapping.

The antithesis of value is waste. Waste is effort spent on anything other than the creation of value. 

Lean recognizes three major types of waste all given Japanese names. Muda, Muri and Mura. - 

Muda is the major form of waste.
Effort spent on non-value creating work. It comes in two types. 

Type one, which is technically waste but necessary for some reason, you know, like compliance. 

And type two, which is just plain wasteful. 

Mura is waste from unevenness. Stopping and starting and context switch. 

And finally Muri is waste from overburdening a person, process, or system. 

The theory of constraints identifies the constraints or bottlenecks that reduce throughput of a system. - By measuring and managing throughput, inventory or queue length and operating expenses and identifying and focusing on the lifting of constraints, you can greatly improve a system's overall delivery. This focus on optimizing the entire process or system's thinking is contrasted to local optimization performed by single functional areas which may actually inhibit the overall flow of the system.

Lean also places a high value upon continuous improvement. It has tools and strategies designed to allow teams to improve incrementally day after day from Kaizen to a host of quality tools. - And finally, respect for and empowering both the individual employee and the team is a critical part of Lean. Work can only be improved by harnessing the knowledge of those performing it. 

Mary and Tom Poppendieck's 2003 book Lean Software Development, an Agile Toolkit, famously adapted these Lean techniques to software development. 

They identify seven principles to follow when developing code. 

You amplify learning by short cycles delivering working code that gets tested and elicits feedback continuously. Deciding as late as possible allows you to make final decisions when you have as much information as you can get. Delivering as fast as possible means you're minimizing the gap between finding out the customer's needs and you fulfilling them, which also reduces waste and the thrash that you can get over a long delivery cycle.

Empowering the team pushes decision making down to the individual. Leadership's responsibility is to educate and empower them to improve their work and the product.Building integrity in focuses on finding and eliminating bugs as early in the process as possible, not passing them on to QA, or worse, the customer. Refactoring, automated testing, and other quality improvement techniques come into play here. And finally, seeing the whole advocates keeping the whole system and product in mind when making decisions.

Lean and agile In DevOps

DevOps is the application of agile methodologies to a system administration. 

The four main pillars of DevOps is CAMS

Culture, automation, measurement, and sharing. 

Mateus Marshall probably summed it up the best in his diagram of the relationship between Lean, Agile, and DevOps.He shows the combination of Agile development, Lean product management, and operations, all as part of DevOps, how the Lean principles of flow informs the entire path of software development process from product conception, through development, to operations.

Thus product development and operations are phases in the pipeline that originate with an idea and ends with something that provides value to a customer. 

Lean is more of a mindset that occurs across all of these phases

Gene Kim introduced the three ways.The principles underpinning DevOps, which are deeply rooted in Lean. 

Systems thinking, 

Amplifying feedback loops, and 

Creating a culture of experimentation and 

Learning are directly out of the TPS playbook. 

https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592