Explore topic-wise InterviewSolutions in .

No. The Sprint BACKLOG is the representation of the tasks that are drawn from the product backlog to achieve the Sprint goal by the development team.  During the Sprint Planning, the development team SETS an objective which is CALLED as a Sprint goal. Only the development team can MAKE changes to the Sprint Backlog as they own it. None changes can be made without the AUTHORIZATION of the development team members.

The MAIN responsibility of the Product Owner is maximizing the value of the project by creating, clearing, and ORDERING the Product Backlog. The Product Owner is the sole person responsible for managing the Product Backlog. The PO prioritizes the product backlog during the Sprint PLANNING meeting for the team members. The PO KEEPS a vision of the product to build and convey that vision to the Scrum team. Also, the role of the PO is to motivate the team towards achieving a project GOAL.

3 HOURS. The DURATION of the Sprint Retrospective meeting varies DEPENDING on the sprint length. For a ONE-week sprint, the meeting should last about one hour; for a TWO-week sprint, two hours. Teams running four-week sprints should allow three hours for this meeting. Sprint Retrospective is a time-box of 3 hours for a one month Sprint. It’s usually shorter when the Sprints are set shorter.

There are five time-boxed events in Scrum: SPRINT, Sprint Planning, Sprint Review, Sprint RETROSPECTIVE, and Daily Scrum. The Scrum Backlog CONSISTS of a list of all the things that NEED to be done WITHIN the project. The Scrum Backlog is maintained all the way through the project.

Yes. The Development Team should be cross-functional, capable of completing the Sprint Backlog items based on the definition of “DONE”. Not every kind of delivery is acceptable in Scrum, it should be “potentially releasable Increments of the FINAL PRODUCT of the PROJECT”, to help the stakeholders to give feedback.

As much as needs to be DONE based on the definition of Done. The Sprint BACKLOG consists of a set of items that deliver the product increment. It is the Development team members that decide what functionality should be INCLUDED in the next increment. The Scrum Team defines “Done” at the END of the project and would not consider that the end-product is COMPLETED unless it matches with the definition of “Done”.

Yes. The Scrum guide recommends that the development team size should be between 3 and 9. We can change the team members as NEEDED while TAKING into ACCOUNT the short-term REDUCTION in productivity. If we add more team members according to the project requirements or if we subtract the team members, in the end, the Development team has to meet the Sprint goal.

BASED on the value of the ITEMS. Scrum GUIDE uses the term ‘ORDERED’ instead of ‘prioritized’ for the Product Backlog. The Product Backlog Items are ordered based on the value of the items. For this, the Development team discusses the PBI ordering with the Product Owner. In the end, the Development team has to has to order the items according to their relative IMPORTANCE to each other.

At any time when done by the Product Owner or at the Product Owner's discretion. The Product Backlog is dynamic; it CONSTANTLY changes to identify what the product needs in ORDER to be APPROPRIATE, COMPETITIVE, and useful. Product Backlog items can be updated at any time by the Product Owner or at the Product Owner's discretion.

The Development TEAM. As a collective, they have a complete VIEW of the WORK needed to transform Product BACKLOG items into INCREMENTS of product. The Product Owner is the sole person responsible for managing the Product Backlog. The PO prioritizes the product backlog during the Sprint Planning meeting for the team members. But, it is the Development Team who is responsible for all the estimates. The people who perform the tasks make the final estimate.

Yes, it can start. The FIRST SPRINT requires no more than a Product Owner, a team, and enough ideas to potentially complete a full Sprint. It is not mandatory that the Product Owner should be READY with the complete and exhaustive Product BACKLOG for STARTING a first Sprint.

Within the Sprint, the Development Team MAKES the best decisions possible to assure progress toward the Sprint Goal, realigning with the PRODUCT OWNER once he/she is available again. In a permanent state of unavailability, a NEW Product Owner NEEDS to be appointed. Development efforts without a Product Owner are not employing Scrum.

TECHNICAL debt causes a greater PERCENTAGE of the product's budget to be spent on MAINTENANCE of the product. The velocity at which new functionality can be CREATED is reduced when you have technical debt.

Through the FREQUENT delivery of Increments of the product into the market. The Product Owner manages Product Backlog against the assumption that value will be generated. This assumption remains invalidated when not checked against USERS and market. When a Sprint's horizon is too long, you increase the risk that what is being DEVELOPED may no longer be DESIRED. Sprints limit risk to one calendar month or LESS of work.

The Product Owner CREATES and sustains a product backlog that maximizes value and REPRESENTS the needs of the STAKEHOLDERS. The PO is also responsible for maximizing the value of the product and the work of the Development Team. The primary tool to do so is the Product Backlog. The Product Owner is the SOLE person responsible for managing the Product Backlog. The PO prioritizes the product backlog during the Sprint Planning meeting for the team members. The PO keeps a vision of the product to build and convey that vision to the Scrum team. Also, the role of the PO is to motivate the team towards achieving a project GOAL.

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. It is a living ARTIFACT of product requirements that exists and evolves as long as a product exists. The Product Backlog evolves as the product and the ENVIRONMENT in which it will be used evolves. Higher ordered Product Backlog items are usually CLEARER and more detailed than lower ordered ones. As long as a product exists, its Product Backlog also exists.

The Product Owner is responsible for maximizing the value of the product. The Product Owner is the sole person responsible for managing the Product Backlog. The PO prioritizes the product backlog during the Sprint PLANNING MEETING for the team MEMBERS. The PO keeps a VISION of the product to build and convey that vision to the Scrum team. Also, the role of the PO is to motivate the team towards achieving a project goal.

They collaborate often so the Product Owner can make informed decisions in balancing effort and value of Product Backlog items. They also collaborate so the Development Team builds INCREMENTS keeping end-user and Stakeholder concerns in mind. The Product owner CLEARLY expresses Product Backlog items, ensuring the Development Team understands items in the Product Backlog to the level needed for developing them and creating the value the Product Owner envisions. The scope may be re-negotiated if the effort grows MUCH higher than ANTICIPATED.

4 hours for a monthly Sprint. For shorter Sprints, it is USUALLY shorter. Sprint Review is a four-hour time-boxed meeting for one-month Sprints. For shorter Sprints, the event is usually shorter.

Sprint Review is held at the end of each sprint. The scrum team shows what they achieved during the sprint in the retrospective meeting. Typically, the sprint review should not take more than one hour per week of sprint DURATION. It MEANS a 30-day sprint WOULD result in four-hour time-boxed sprint review. SIMILARLY, two-hour review for two weeks sprint. Finally, the length of your sprint review depends on the length of your sprint.

The primary purpose of a Sprint is to PRODUCE a done increment of working product. The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", USABLE, and potentially releasable product Increment is created. The more “Done” the increment is, the more useful the feedback that is gathered will be. If something is 99% done, and only 1% work is REMAINING - it is STILL NOT DONE, and it has to be added back to the product backlog and re-estimated during the next sprint.

No. Scrum does not have a defined role CALLED “project manager”. A Scrum TEAM has a Scrum Master, a Product Owner, and a Development Team. As a whole, they have all the controls needed. The project manager role doesn’t EXIST in a Scrum environment, but the core responsibilities of a project manager do exist LIKE the responsibility of date, scope, budget ETC. Many of the responsibilities of a traditional project manager are fulfilled by these roles. So, there is no specific role called project manager when using Scrum.

As NEEDED, while taking into account a short-term reduction in PRODUCTIVITY. Teams typically GO through some steps before achieving a STATE of INCREASED performance. Changing membership typically reduces cohesion, affecting the performance and productivity in the short term.

8 HOURS for a monthly Sprint. For SHORTER Sprints, it is USUALLY shorter. Each Sprint BEGINS with the Sprint PLANNING meeting. Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. For example- for a two-week sprint, the Sprint Planning meeting can be of 4-hours.

The Product Owner. The Product Owner is the SOLE PERSON responsible for managing the Product Backlog. The PO prioritizes the product backlog during the SPRINT Planning meeting for the team members. The PO KEEPS a vision of the product to build and CONVEY that vision to the Scrum team. Also, the role of the PO is to motivate the team towards achieving a project goal.

It means the event can take no more than a maximum amount of time. Time-boxed EVENTS are events that have a maximum DEFINED duration. For Example- Daily Scrum MEETING is ONE of the timeboxed ceremonies in the Scrum. This event is timeboxed for 15 minutes (not more than that) and usually held at the same time and place each day. Also, it is usually held at the morning time when maximum team MEMBERS gather to plan work for the whole day.

To support the Product Owner with insights and information into high-value product and system capabilities and to support the Scrum Master to CAUSE organizational change that fosters empiricism, self-ORGANIZATION, bottom-up intelligence, and intelligent release of the software. Management has no active ROLE in actual product development through Scrum. However, management external to the Scrum team is incredibly important in setting the vision and strategy to guide the OVERALL PROCESS to the team for developing a product in the organization.

The ability to turn the PRODUCT Backlog ITEMS it selects into an increment of POTENTIALLY releasable product FUNCTIONALITY. The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the END of each Sprint. The Development Teams are cross-functional teams, with all of the necessary skills as a team to create a product Increment.

Consistency reduces complexity. The purpose of the DAILY Scrum meeting is to CARRY out communication between the TEAM members. The Scrum meeting is timeboxed to 15 minutes irrespective of the team-size and is held at the same time and PLACE each day to REDUCE complexity. Also, it is usually held in the morning time when maximum team members gather to plan work for the day.

Whatever is deemed most appropriate by the PRODUCT Owner.The Product Owner decides what makes the most sense to optimize the value of the WORK being DONE by the Development Team. The product backlog is ordered based on the value provided to the business. The value may be affected by various other FACTORS like complexity, criticality, and risk but are not the direct basis for calculating the value. The item value being delivered is calculated by the product owner and he/she is responsible for ORDERING the product backlog.

It is when the Scrum TEAM and stakeholders inspect the outcome of a Sprint and figure out what to do next. Every event in Scrum, besides the Sprint which is a container for the other EVENTS, is an opportunity to Inspect and Adapt. A Sprint Review is CONDUCTED at the end of the Sprint to inspect the increment and adapt the product backlog if required. During this, the Scrum Team and Stakeholders collaborate about what was done in the Sprint and figure out any changes to be done to the product backlog during the Sprint to optimize value. TYPICALLY, this meeting is a form of the DEMO of the new features.

When the TIMEBOX expires.The duration of a Sprint is fixed and cannot be shortened or LENGTHENED. For example, if all the items of a Sprint are not done, the Sprint is STILL marked as over and the remaining items are moved to the product backlog from where it can be scheduled to any of the following sprint based on the revised priority. Similarly, if all the items of a Sprint are done before time, the dev TEAM is free to PICK top PBIs and start working on it.

The Product OWNER is responsible for maximizing the value of the product and the work of the Development Team. He/she is the voice of the CUSTOMER. PO DETERMINES the scope of a product and release dates. The PO can attend all the meetings to keep track of the team’s PROGRESS. If there are any changes that need to be done, it will be implemented immediately. The product owner wishes that the team will be ABLE to achieve its goal with the timetable.

Development team, product owner, SCRUM master. The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. As the Scrum teams are cross-functional, the development team includes designers, ops ENGINEERS, and testers in addition to developers. Each of the Scrum roles has DEFINED a set of responsibilities and they can COMPLETE a PROJECT successfully only if they accomplish these responsibilities, closely work and interact together.

Ideally, it is 3-9. Scrum says team size of 6+ or -3 is the Scrum GUIDE recommendation. Optimal Development Team size is small enough to remain nimble and LARGE enough to complete significant work. Fewer than three Development Team members decrease INTERACTION and results in smaller productivity gains. More than nine members simply REQUIRE too much coordination.

The length of a daily Scrum is fixed at 15 minutes for the development team to a create plan for the NEXT 24 hours and synchronize activities, it does not change with the length of a SPRINT. This OPTIMIZES team performance and collaboration by analyzing the work since the last Daily Scrum and predicting the forthcoming Sprint work. This Daily Scrum meeting is conducted at the same place and TIME each day to minimize complexity.

Scrum is a FRAMEWORK within which complex products in complex environments are developed. Scrum is not a process or a technique for building products; rather, it is a framework within which you can EMPLOY various processes and techniques. Scrum Framework is applied to the complex projects in complex environments. If a Scrum team adheres to the Scrum practices, it will help in DEVELOPING the best quality product within a SPECIFIED TIMEFRAME.

The Product Owner actively asks for stakeholder’s INPUT and expectations to PROCESS into the Product Backlog. The Product Owner REPRESENTS the Stakeholders to the Scrum Team, which includes representing their DESIRED requirements in the FORM of Product Backlog. The Product Owner has the final call over the Product Backlog.

Inspection, Transparency, ADAPTATION. Scrum is founded on empirical process CONTROL theory or empiricism. Empiricism asserts that knowledge comes from experience and making decisions BASED on what is KNOWN. The three pillars uphold every IMPLEMENTATION of empirical process control are transparency, inspection, and adaptation.

The DEVELOPMENT Team is responsible for MANAGING the progress of work during a Sprint. The Development team is comprised of professionals who work in a Sprint and DELIVER a potentially releasable product at the end of each Sprint. These increments are created by only the members of the Development team. The Development Team uses the DAILY Scrum to inspect a progress toward the Sprint Goal and to inspect how progress is trending TOWARDS completing the work in the Sprint Backlog.

This is the task of the Product Owner. The Product Owner is the sole PERSON responsible for managing the Product Backlog, which includes that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next. The responsibility of achieving maximum business VALUE for the PROJECT lies primarily with the Product Owner. The PO is also responsible for maintaining business justification for the project and articulating customer requirements. A PO represents the VOICE of the customer.

The next sprint BEGINS immediately after the conclusion of the previous Sprint. A sprint begins with Sprint PLANNING meeting and concludes with Sprint Retro. In GENERAL, planning for the subsequent Sprint starts after the conclusion of the previous sprint. So, typically the plan for the next Sprint is fixed by the TIME the previous sprint ends. The actions from the RETROSPECTIVE and demo will go in the product backlog and can be prioritized in a future sprint.

Deliver an increment of releasable software, and develop and deliver at least one piece of functionality. The heart of Scrum is a Sprint, a time-box of one MONTH or less during which a "Done", useable, and potentially releasable PRODUCT Increment is created. This APPLIES to every Sprint. The first Sprint conducted by the DEVELOPMENT team plays a key ROLE in the Scrum. It also focuses on estimating the availability of the team, selecting the items from the product backlog, and final thoughts. During the first sprint, the development team delivers an increment of releasable software. They also Develop and deliver at least one piece of functionality.

The Development Team and the PRODUCT Owner are responsible for product backlog refinement. During a product backlog refinement meeting, the product owner and the development team communicate and decide the TOP items on the product backlog. The team can raise queries during the SPRINT planning session if they find any unresolved issue. The Product Owner and team can discuss with the Stakeholders to find out “what” they want and “why” they want. Once if they are CLEAR with the user NEEDS then they can go for the cross-checking with teams.

The DEVELOPMENT TEAM can participate in the product backlog refinement anytime during the sprint. Product Backlog refinement is a continuous PROCESS in which the development team and the product owner COLLABORATE anytime needed during the Sprint on the details of Product Backlog ITEMS. PBR is required in each and every Sprint to refine items to be ready for future Sprints. The Scrum team decides when and how refinement is done.

There is no such thing as SPRINT 0. It is not a valid Sprint from Scrum timeboxed events. "Sprint 0" has BECOME a phrase MISUSED to DESCRIBE the planning that occurs prior to the first sprint like refining product backlog, architecture envisioning, prioritizing and RELEASE planning etc. This term is confused with the term  "Release 0". It is ideal to talk about Release 0 as opposed to Sprint 0.

The DAILY Scrum is for the people transforming the Product Backlog items into an Increment. Only the people that are building the product should be present at the Daily Scrum. The Scrum MASTER ENFORCES the rule that only Development Team members participate in the Daily Scrum to share information with each other that can help them to understand how to organize the work among the team members in a better way to meet the SPRINT Goal.

The Sprint duration should be short enough in order to keep the TEAM focused and also, to keep the business risk acceptable to the PRODUCT Owner. Ideally, the sprint length can be short enough to be able to synchronize the development work with other business events. The Scrum guide limits the Sprint length to 1 MONTH but there is no OFFICIAL lower LIMIT. So, 1 week can be often accepted as the shortest sprint duration. So, you can find the length that is best for your team in between 1 week - 1 month.

Progress on Scrum project can be tracked by means of a Release burndown chart.

The vertical AXIS shows the number of story points remaining on the project. Iterations are shown across the horizontal axis. A release burndown chart shows the amount of work remaining at the start of each iteration. This becomes a powerful visual indicator of how quickly a team is moving toward its goal. In the below chart the work is expected to be COMPLETED in 7 iterations with 120 story points. First 3 iterations the schedule is behind maybe work has been added or re-estimating of few stories. Then the work is on track and after that, the team made good progress and completed the work.

The burndown chart is an essential PART of any agile project and is a way for the team to clearly see what is happening and how progress is being made during each sprint.

This Bar GRAPH shown below is also commonly used to plan release planning.

There are THREE different ways of estimating velocity.

• First, we can have HISTORICAL averages if we have them. But before using this average whether there have been significant changes in the TEAM, the nature of the project, the TECHNOLOGY, team, etc.
• Second, we can run a few iterations until we finalize on stable velocity (Pilot project).
• Third, we can forecast velocity by breaking a few stories into tasks and seeing how much it will take to complete an iteration. This process is very similar to iteration planning.

As this is the velocity of the first sprint so that will be rough estimate by the team based on the CURRENT knowledge on hand. They are just forecast not set in stone in any way.

Do not take this value as a commitment as this is just an estimate.

After 3-4 sprints team is mature enough to decide on the story points needs to be taken into consideration for the sprint, so even if we go wrong in the first sprint, next 3-4 sprint will give us correct data on velocity.

As shown in the figure below the average velocity is 30.5.

Below table clearly defines when to use Scrum.