Agile & Scrum Interview Questions and Answers

Epic: A customer described software feature that is itemized in the product backlog is known as epic. Epics are sub-divided into stories. User Stories: From the client perspective user stories define project or business functions, and delivered in a particular sprint. Task: Further down user stories are broken down into different tasks.

User stories are features customers might want to see in their software. They are written on index cards to encourage face-to-face communication. Typically no more than a couple days work, they form the basis of our Agile plans.

An Agile iteration is a short one to two week period where a team takes most important user stories, builds them completely and deliver as running-tested-software to the customer. Analysis, design, coding, testing happen during an iteration.

Scrum is one of the most popular frameworks for implementing Agile. Many people think scrum and agile are the same thing but they're not. With scrum, the product is built in a series of fixed-length iterations called sprints that give teams a framework for shipping software on a regular cadence.

To improve the performance or readability, the existing code is modified; this is re-factoring. During re-factoring the code functionality remains same.

In the Scrum methodology a Sprint is the basic unit of development. Scrum sprints correspond to Agile iterations. Each Sprint starts with a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made. A Sprint ends with a review or retrospective meeting where the progress is reviewed and lessons for the next sprint are identified. During each sprint, the team creates finished portions of a product.

Three essential roles for scrum success are: The Product Owner are the champions for their product. They are focused on understanding business and market requirements, then prioritizing the work to be done by the engineering team accordingly. The Scrum Master are the champion for scrum within their team. They coach the team, the product owner, and the business on the scrum process and look for ways to fine-tune their practice of it. The Scrum Team are the champions for sustainable development practices. Scrum teams are cross- functional, "the development team" includes testers, designers, and ops engineers in addition to developers.

In Scrum the task board is a visual display of the progress of the Scrum team during a sprint. It presents a snapshot of the current sprint backlog allowing everyone to see which tasks remain to be started, which are in progress and which are done. Consider the following layout of the task board: Stories To Do In Progress Testing Done

A product roadmap is referred for the holistic view of product features that create the product vision.

Product backlog: It contains a list of all desired features and is owned by the product owner Sprint backlog: It is a subset of the product backlog owned by development team and commits to deliver it in a sprint. It is created in Sprint Planning Meeting

Test Driven Development (TDD) is also known as test-driven design. In this method, developer:

1. first writes an automated test case which describes new function or improvement and
2. then creates small codes to pass that test, and
3. later re-factors the new code to meet the acceptable standards.

To track the project progress burnup and burn down, charts are used: Burnup Chart: It shows the progress of stories done over time Burndown Chart: It shows how much work was left to do overtime

It is used to discuss the** difficulty of the story** without assigning actual hours. The most common scale used are a Fibonacci sequence (1, 2, 3, 5, 8,1 3,….100) although some teams use

Linear scale (1, 2, 3, 4….) ,
Powers of 2 (1, 2, 4, 8……) and
Cloth size (XS, S ,M, L, XL)

Velocity is a metric that is calculated by addition of all efforts estimates related with user stories completed in an iteration. It mesures how much work Agile can complete in a sprint and how much time will it need to finish a project.

If a timebox plan needs to be reprioritized it should include whole team, product owner, and developers.

The burn-down chart shows the remaining work to complete before the timebox (iteration) ends.

Agile is a time boxed, iterative approach (framework) to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end. It works by breaking projects down into little bits of user functionality called user stories, prioritizing them, and then continuously delivering them in short two week cycles called iterations. Agile refers to any process that aligns with the concepts of the Agile Manifesto.

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Sprint Backlog is the set of Product Backlog items selected for the Sprint during the Sprint Planning, plus a plan for delivering the product Increment and realizing the Sprint Goal.

The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.

Sprint Planning answers the following: What can be delivered in the Increment resulting from the upcoming Sprint? How will the work needed to deliver the Increment be achieved? The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog.

Scrum calls for four ceremonies that bring structure to each sprint: Sprint planning: A team planning meeting that determines what to complete in the coming sprint. Daily stand-up: Also known as a daily scrum, a 15-minute mini-meeting for the software team to sync. Sprint demo: A sharing meeting where the team shows what they've shipped in that sprint. Sprint retrospective: A review of what did and didn't go well with actions to make the next sprint better.

Analysis, design, coding, and testing are continuous activities Development is iterative Planning is adaptive Roles blur Scope can vary Requirements can change Working software is the primary measure of success

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face- to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity - the art of maximizing the amount of work not done - is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The core Scrum Values upon which the Scrum framework is based Commitment - we commit to ... Focus - we focus on ... Openness - we are open to ... Respect - we show respect ... Courage - we show courage ... People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.

Continuous Integration is important for Agile for following reasons: It helps to maintain release schedule on time by detecting bugs or integration errors Due to frequent agile code delivery usually every sprint of 2-3 weeks, stable quality of build is a must and continuous integration ensures that In helps to maintain the quality and bug free state of code-base Continuous integration helps to** check the impact of work on branches** to the main trunk if development work is going on branches using automatic building and merging function

Scrum theory is based on an empirical process or empiricism where progress is based on observations of reality, not fictitious plans. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk by using three pillars of empirical process control: transparency - means presenting the facts as is inspection - the process of inspection of Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances adaptation - is the ability to adapt based on the results of the inspection

An Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release/deploy it on any environment.

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. During the Sprint Retrospective, the team discusses: What went well in the Sprint What could be improved What will we commit to improve in the next Sprint The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.

Scrum is a specific flavor of Agile. Scrum is not a methodology. It simply provides structure, discipline and a framework for Agile development. Agile and Scrum are related but distinct. Agile describes a set of guiding principles for building software through iterative development. Agile principles are best described in the Agile Manifesto. Scrum is a specific set of rules to follow when practicing agile software development described by Scrum Guide (official Scrum Body of Knowledge).

Before using Agile methodology, you must ask following questions Is functionality splitable Is customer available Are requirements flexible Is it really time constrained Is team skilled enough

Agile quality strategies are: Re-factoring Non-solo development Static and dynamic code analysis Reviews and Inspection

Iteration/sprint demos All hands demo Light weight milestone reviews Short feedback cycles Standards and guidelines

Iterative: Iterative method is a continuous process of software development where the software development cycles are repeated (Sprint & Releases) till the final product is achieved. Incremental: Incremental development segregates the system functionality into increments or portions. In each increment, each segment of functionality is delivered through cross-discipline work, from the requirements to the deployment.

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.

Scrum: Scrum teams usually have to work in iterations called sprints which usually last up to two weeks to one month long Scrum teams do not allow change into their sprints In Scrum, the product owner prioritizes the product backlog but the team decides the sequence in which they will develop the backlog items Scrum does not prescribe any engineering practices

Extreme Programing (XP): XP team works in iteration that last for one or two weeks XP teams are more flexible and change their iterations XP team work in strict priority order, features developed are prioritized by the customer XP does prescribe engineering practices

Scrum Master key responsibilities involves: Understand the requirements and turn them into working software Monitoring and Tracking Reporting and Communication Process Check Master Quality Master Resolve Impediments Resolve Conflicts Shield the team and performance feedback Lead all the meetings and resolve obstacles

The advantages are It helps team to objectively measure progress It provides a consistent means of measuring team velocity It helps to establish a consistent pattern of delivery

Challenges involved in Agile Software development includes: It requires more testing and customers involvement It impacts management more than developers Each feature needs to be completed before moving on to the next All the code has to work fine to ensure application is in working state More planning is required

In February 2001, 17 software developers met in Utah to discuss lightweight development methods. They published the Manifesto for Agile Software Development, which covered how they found “better ways of developing software by doing it and helping others do it” and included four values and 12 principles.

Acceptance criteria is a metric/statement/list of done definitions the product owner uses to confirm the user story has been implemented to his satisfaction.

The Scrum Framework consists of Scrum Team that consists of: The Product Owner The Development Team The Scrum Master and associated Events: The Sprint Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Artifacts: Product Backlog Sprint Backlog Increment

A Burndown Chart is a graph that shows the progress of the team in terms of work burned through. The work is usually put in terms of a set of story points which represent functionality. Once a piece of functionality is coded and tested and reviewed by the user, it is considered to be burned and the graph will reflect this. The graph should show a steady movement down until it is clear that the team will have completed the story point backlog by the release date.

Project velocity is the rate at which a team is "burning" through story points, so a possible velocity might be "30 story points per iteration." That means that so far, the team has been able to identify, code and test 30 units of functionality (story points) in an average iteration and can expect to do about that much in future iterations, giving a fairly good view towards what can be accomplished by a release date.

Agile is a framework and there are a number of specific methods within the Agile movement, for example:

Extreme Programming (XP)
Scrum
Lean Software Development
Kanban
Crystal Clear

While there is value in the items on the right, agile team value the items on the left more:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

When a Product Backlog item or an Increment (set of items) is completed and that understanding is shared all across the Scrum Team the item is considered as Done . The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of Done .

Burn-up Chart is a chart which shows the amount of work which has been completed. Time is shown on the horizontal axis and work completed on the vertical axis. As time progresses and items are drawn from the backlog and completed, a plot line showing the work done may be expected to rise. Consider:

Burn up charts highlight the variability in your project and help identify options to adjust the course of your project: Total scope variability from feature additions and cuts. Team velocity variability from inherent uncertainty of feature complexity, interruptions, or burnout. Future projection variability, transparently illustrating the range of potential end scenarios given velocity variability. Once a team has a few good sprints worth of data recorded and team's velocity is known the burn up chart can help visualize the options for adjusting a project plan to keep it on track. Consider to reduce scope by X points to preserve budget and calendar deadlines:

Consider to increase budget and extend calendar deadlines to deliver all scope

Sprint Zero: It is introduced to perform some research before initiating the first sprint. Usually this sprint is used during the start of the project for activities like setting development environment, preparing product backlog and so on. Spikes: Spikes are type of stories that are used for activities like research, exploration, design and even prototyping. In between sprints, you can take spikes for the work related to any technical or design issue. Spikes are of two types:

Technical Spikes and Functional Spikes.