Explore topic-wise InterviewSolutions in .

A good scrum team is first of all, a self-organizing team and an empowered team. What does this mean?

This means, the team:

• Takes responsibility to continue making progress in spite of all blockers
• Is fully accountable for the deliverables given to the customer
• Tries to make sure they divide the work among themselves in a fair manner and they take up new tasks once they finish their tasks
• Respects each other qualities and abilities and complement each other by picking up skills as PER their strong areas
• It is open while discussing issues and blockers and aims to solve problems rather than indulging in blame game or INTERNAL politics.

A scrum master enables this behavior by being a great coach and always following in what they themselves PREACH. Scrum values of Courage, focus, commitment, openness and respect become part of LIFE and actions at all times. Other ways, a scrum master can enable this in the team is by:

• Understanding team development process [bruce tuckman model]
• Connecting with team member on their MOTIVATION level [maslow’s heirarchy of needs]
• Enabling system thinking in the team
• Usage of information radiators
• Workshops
• And most importantly, leading by example.

Sprint 0 is a concept that team needs some time to settle down before delivering actual value to the customer from sprint 1. But it has been misused a lot LATELY as an excuse to put everything in place then go for sprints. So essentially, the misuse is LIKE doing waterfall in Agile projects.

The correct way of doing sprint 0 is when the REQUIREMENTS are very VAGUE that no user story can be started off or the TECHNOLOGY is completely new for the team or the project is so complex that there needs to be a dedicated time for product discovery. In such cases, sprint 0 should be allowed where team resolves these issues and is not bound to deliver any value.

A spike is a duration of time included in the sprint planning to ALLOW the team to explore new tasks, plan for next SPRINTS, do research for new ways of solving a problem or EVEN to collaborate to RESOLVE blockers. The team can use this time to get trained on technical or softer aspects also. Having a spike in the schedule builds in the flexibility for the unknown issues that MIGHT crop up during the sprint execution.

The QUESTION about “SHALL the team GET involved” does not arise in Agile and SCRUM because entire Scrum team gets involved in the product discovery process.

This HELPS by:

• Facilitating learning and growth WITHIN the team as they solve NEW challenges
• Improving ownership of the product and hence the quality
• Faster and on time delivery
• Accountability and responsibility for tasks and features
• Problem solving mindset that comes with the attitude of can do.

Self-organizing is a very important concept in the Scrum framework. “The BEST architectures, requirements, and designs emerge from self-organizing teams”, the Agile Manifesto states.

Self-organizing as the name suggests taking responsibility, SHOWING ownership and having accountability. The team removes obstacles on its own WITHOUT waiting for a manager or somebody else to come and tell them what to do. Teams choose the best way to do work (tools, technology etc.) and strive hard to accomplish their SPRINT goals rather than directed by managers from outside the team. They have the best skills, knowledge and abilities, which make them right and best, fit to take decisions on their own. Fail fast rather than at the end should be their working MODEL. Experiment with approaches and learn from failures and continuously adjust and adapt. Sometimes self-organization is also called self-optimization.

Scrum Master’s job is to make sure the scrum is being followed and applied in a CORRECT way.Below are a few checkpoints where you can judge if the scrum process is correctly applied or not.

1. Is team self-organized?
2. Does the team understand the sprint goal and working towards it or they are working on individual goals?
3. Does the team collaborate more and share their feedback openly?
4. In the retrospection, are you getting any inputs from the team on where they need to improve?
5. Is the team transparent in NATURE?
6. Is the team working on inspect and adapt the model?
7. Is the team mature enough to HANDLE if there is a sudden change in requirement from the customer side?
8. Is Definition of done followed whenever the user story is READY for review?
9. Do we have information radiators available for everyone to see and review?
10. Are there more face to face conversations or emails?
11. Does team work in a Silo?
12. Does the team work on an incremental and iterative model?
13. Does the team THINK themselves as a Scrum team member, a developer or a tester? If yes, then as a scrum master you need to improve on that mindset?

With the help of STATISTICS from the Chaos report of the Standish group, we can build upon the case that adopting Agile improves the success ratio of the projects. It helps timely DELIVERY, COST control and BUILDING better PRODUCTS in a relevant amount of time.

Minimum Viable product also known as Minimum Marketable feature is a criteria that helps the Scrum team know the bare minimum level they have to deliver before it will be accepted by the customer.

So the PO clearly outlines the MVP or MMF list and tries to target them in the first sprint itself, so that basic customer expectations can be met from sprint 1.

For example: consider a mobile phone company releasing the 1st version of their latest mobile phone that has all the features such as Artificial intelligence and wonderful aesthetics but is unable to MAKE a phone call because that feature will be released later. Do you think you will buy that mobile phone?

No, right?

So for a mobile phone, ability to make a phone call is a MVP or MMF criteria.

“A learning vehicle” ~ Eric Ries

The most commonly misunderstood term is MVP. Most people think it means the Product with minimum features and functionalities. But this is not true.

MVP means “A minimum viable product is one that already has sufficient attributes to ALLOW you to test its value proposition and business model for which you intend to create when marketing it”.

MVP is the stage of development in which we SUM up all the features, test it and deliver to the market to get the response from the market. So we are not investing too much money and effort, but just to get feedback from the customers so that we can inspect and adapt accordingly.

As Ries explains in Lean STARTUP, “It is not necessarily the smallest product imaginable, though; it is simply the FASTEST way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort … Its goal is to test fundamental business hypotheses.”

Example-If we want to start a new Ethnic wear company, I could test my vision by making some sketches and stand in some malls or busy market place to get the feedback from customers. I can also put those images on the webpage and ask them to click if they like or any comments/feedback. Both the approaches will give me an idea of people mind about the wear which people has shown more interest. Accordingly, I can base (colour and design) my ethnic wear collection.

Read more in Product Discovery process in question Do you think Scrum adequately addresses the product discovery process.

BIGGEST advantage is the continuous value delivery to customer and HENCE, a CLEAR MESSAGE to the project team about whether they should continue in that path or not.

SCRUM is not required where the goal and ask if the customer is small in scope and very straight forward. Similarly, if the scope of the project is huge and DEPENDENCIES are not known and project is expected to run into years then the overall framework of the project should be TRADITIONAL [waterfall] with small tracks in that project running in ITERATIVE mode.

 This is important because:

• It INCREASES the efficiency of the team by reducing uncertainty and unknowns from USER stories.
• It helps weed out redundant and not required anymore type of scenarios
• It helps adjust the ESTIMATES and priorities at the GIVEN POINT of time
• Sprint planning becomes a matter of few minutes if backlog is groomed properly.

In total there are 4 ceremonies. Planning, daily SCRUM, REVIEWING and demo, retrospective. If you are asking about some activities that take place before the planning then backlog grooming is ALSO one such activity but that is an on-going activity. And done by PO PRIMARILY.

In case the scrum MASTER is on planned vacations or out on some EMERGENCY, there is always a backup PERSON who can PITCH in. In their absence, the Scrum team is responsible to carry out the daily activities with full dedication and responsibilities. However, I have SEEN cases where another Scrum master have lend their time in the absence or PO or PM pitches in for some time.

No, it cannot be and should not be. A THOROUGH and DETAILED REVIEW should be DONE to check suitability. Check this blog for more details: 

https://www.knowledgehut.com/blog/agile/does-scrum-apply-to-all-types-of-projects

Like other METHODOLOGIES Scrum is also not suited for all types of projects. It is with due diligence this needs to be decided on project and situation basis.

Scrum is less formal and more flexible, due to this NATURE larger organizations have difficulty in adopting it as they are RIGID in their POLICIES and processes.

The problem mainly arises when the TEAM does not understand either value of the process of Scrum and also not flexible enough to adapt change in requirements. Also without proper guidance and monitoring, this can be used as an excuse for delivering poor quality work

Not any ONE individual is RESPONSIBLE for the deliverables. Deliverables cannot be ACHIEVED until and unless the whole TEAMWORK COLLABORATE. It is the entire Scrum team who owns deliverables.

Requirements are expressed in the form of user stories in Agile. Every feature request is aligned in the form of 3-4 user stories that can be completed over a PERIOD of TIME. Each user story contains certain aspects of the functionality and hence, several requirements. IDEALLY, when 1 user story gets broken down further, it leads to 10-12 requirements or tasks.

Acceptance criteria of the user stories is a way of TELLING how the stories will be evaluated and certified upon completion. Complete collection of user stories is a product backlog that is continuously groomed and maintained by the Product owner.

Product backlog gets prioritized and estimated as per release plans and hence, requirements get managed in a more emphatic manner in Agile.·         

Time BOXING concept is aligned to make best use of time and remove unwanted distractions by MAKING the team more FOCUSED. It is like packing a suitcase where you have fixed amount of space and you try to fit in as much as possible or required for your travel.

So in time boxing, the tasks are broken up in fixed sizes and team works on them. Since the time is fixed, so there is INCREASED focus of the team to make the best use of time.

To get the best value from time boxing, try to have a reasonable time box window that is neither too HARSH nor too lenient.

The ideal size of the team is 5 to 9 as per the Scrum guide (excluding Scrum Master and PO). If Scrum Master is also a developer, include him on the team. Collaboration is difficult if the team size is more. A KEY benefit of five to nine-member team is that communication and management are typically simple and REQUIRE minimal effort. If the team size is less than 5 than my OPINION is that we will not be able to cover all the skill set which is required to fulfil the demand of the project magic FIGURE of 5 to 9 came after long research by Mike Cohn and beautifully explained with “2 Pizza teams.” Book -SUCCEEDING with Agile.

It would be wrong to choose anyone of them. Because they together GIVE the best VALUE. Using iterative model, you can GET feedback incorporated in your project delivery and hence, provide better value for money to the customer. Whereas incremental delivery allows you to ship CONSISTENTLY at a regular sustainable pace.

Choosing one at the cost of ANOTHER is not a great idea. So Agile tries to merge both models into one.

However, still if the interviewer forces you to choose then say, if the requirements, timelines, designs are very well known and clearly articulated without any confusion then incremental is better. Because iterative model helps in product discovery in case of ambiguity.

SCRUM is an iterative model of PRODUCT/project delivery. The only difference is that at the end of SPRINT, we also deliver an incremental product. Other than that there is no difference. You should note this QUESTION is to test your knowledge of concepts.

For example:

SCRUM, one of the "Agile Methodologies", is a well-defined set of guidelines that govern the development process of a product, from its design stages to its completion.

Product owner first creates list of user stories along with acceptance criteria. This is akin to requirement description stage in Waterfall model. In Agile, this list is known as product backlog. So PO, does UPDATE the proposed value of the stories that will help us in right prioritization.

1. During sprint planning team pulls the necessary user stories from the sprint backlog, do estimation, and decide on how much work NEEDS to be pulled.
2. The duration of the sprint is generally 2-3 weeks to complete its defined work for one sprint, but team meets daily (Daily Scrum) to assess its progress.
3. Along the way Scrum Master keeps them FOCUSED on a single goal.
4. At the END of the sprint, the work should be in potentially shippable-all quality metrics completed and ready to hand it over to the customer.
5. The sprint ends with a sprint review and retrospection.
6. After this, the next cycle or sprint begins and the cycle continues till all of the requirements of the product backlog completed.

Important POINT to note here is that Scrum master does not manage the TEAM [unless they are playing the role of manager also]. Scrum master most often leads the team. So you can CLARIFY this point with the interviewer and then explain about your past EXPERIENCES where you led more than 1 team.

If you have done any certifications then do LIST them out. <<INSERT links for KnowledgeHut Trainings REGISTRATION>>

Many times. Especially when the team is new and they are figuring their way out in the project. SHARE the experience where you have helped unblock your team but make sure your answer includes the following aspects:

• How you found out about the issue or the roadblock. Most often, this gets noticed during daily scrum meetings and through information radiators.
• Then elaborate on how you dug deeper to UNDERSTAND the root cause of the issue. So talk about techniques such as 5-Whys and FISHBONE diagram
• Then talk about how you leveraged your SOFT skills and knowledge of Agile to connect with stakeholders to get things moving or getting the problem resolved. For example: you might have reached out to someone, or used your negotiation skills etc.
• Then talk about the solution that you got

For example: 

The team was consistently reporting since last 2 days that their test automation status was 50% and they were doing the investigation for failures. So on the 2nd day, I asked details about the failures and using the 5-why technique, I drilled down to the fact that it had to do something with the build that was released on day before yesterday. So I reached out to the build team and helped establish connect with my team. Using my negotiation skills, we leveraged the use of our automation to save their build time and in return, they would prioritize the fixes our team needs. So we were able to resolve the issue next day and going FORWARD my team worked directly with the build team because I enabled them.

This question is intended to check your grasp on the concepts of Agile and Waterfall.

Yes, there are scenarios where using Waterfall is more recommended over Scrum. The most common scenario is when the requirements, design, and TIMELINES are well defined. Then you do not need any product discovery or iterations. You simply do waterfall in such cases and deliver the product.

Similarly, if you have been assigned a complex project of a large scale where nothing is KNOWN; not even the boundaries of the project then it is recommended to proceed with waterfall and as things become clearer along the way then you should implement Scrum for those small PIECES. So in the end, you will have several scrum projects running under a waterfall program.

A sort of HYBRID MODEL.

• YES, Scrum is an Agile Framework. Other agile methodologies are Kanban, XP (Extreme Engineering, Lean THINKING).
• This same QUESTION can ALSO be asked to you as “Do you know any other methodology apart from Scrum?”

Artifacts are the documents that are used in Scrum. They not only document the progress made so FAR in the sprint but also serve as a guide for upcoming milestones.

• Scrum Artifacts are: Product backlog, Scrum backlog, incremental product, definition of DONE, information radiators.
• Product backlog is collection of all work items that need to get done over a period of time or before PROJECT closure. These are items that entered after discussion with CUSTOMERS and end users. Just because an item is in backlog, does not mean it will get done for sure. It has to be backed with good value and the right cost.
• Sprint Backlog is the list of work items that are subset of product backlog and are taken up by Scrum team for a given sprint. This is a tentative commitment by team to deliver by end of sprint. Again, having an entry in sprint backlog does not GUARANTEE its success or completion.
• Incremental Product: The piece of working software that is delivered at the end of sprint and gets merged to the existing main product and hence, providing incremental value to the customer continuously is the incremental product. This is considered as artifact in Scrum

The main qualities a Scrum MASTER should possess are:

1. Responsible
2. Humble
3. Collaborative
4. Committed
5. Influential
6. Knowledgeable

The prime responsibilities of a Scrum Master are:

1. Removes the obstacles/impediments that AFFECT productivity.
2. Shields the people from external disturbance.
3. Responsible if the scrum process is correctly applied.
4. Facilitate daily stand-ups, other ceremonies, schedule meetings, demo and other meetings.
5. Help PRODUCT owner in prioritizing the backlog and any feedback from the team.
6. Facilitation of Retrospective meetings
7. Workshops for planning, estimation, PRIORITIZATION, issue resolution, performance improvements

This QUESTION is intended to check if you CLEARLY know where each item lines up. Agile is a framework, a WAY of doing things. WHEREAS Scrum is a methodology i.e. a method to do Agile. Similarly, there are many more methodologies in the market, such as Lean, Kanban, XTREME Programming, Crystal Clear.

Impediments are obstacles or issues that comes in between the path of the SCRUM team due to which their SPEED SLOW down or they are not able to move forward with their WORK. Scrum Master should be primarily responsible for handling this SITUATION. If something is trying to block the work of the Scrum team from moving the state from “In Progress” to “Done” state is an impediment.

Impediments may come in any form, few examples are:

1. Dependency issues with other teams.
2. Organizational and Business issues.
3. A team is not trained on the Scrum Process.
4. Technical Debt.
5. Unplanned work
6. Lack of skill and knowledge.
7. Resource management.
8. Lack of management support.
9. External issues- natural calamity etc.
10. No clarity in requirements.

Agile clearly STATES that PO, Business, STAKEHOLDERS and development team should be in close coordination for the entire duration of the project, sprint, and release. So the scenario mentioned here is not POSSIBLE and should be discouraged at all costs.

In exceptional cases, where PO is INDISPOSED and is unavailable then Project manager, Scrum Master, team should come together to make sure the vision and roadmap is not disturbed and progress continues in the planned manner.

PO is responsible for making SURE the releases and sprints align with the product roadmap and business case over a period of time. So as part of those RESPONSIBILITIES, the PO regularly:

1. Groom product backlog
2. Communicates and clarifies the vision to the team
3. Involving the right people
4. Work closely with Team, Scrum Master, Stakeholder and marketing team.

In order to make sure the product REACHES the state where everyone wants it to be, the PO NEEDS to be totally in sync with customer EXPECTATIONS, team progress, and roadmap.

Ideally, this should not be the CASE because the Product Owner and Scrum MASTER always attend the DAILY scrum meetings and monitor the information radiators to check the health of the sprint. So the probability of something like this happening is low.

Still if it happens then it should be discussed, reviewed and taken up for discussion in sprint retrospective meetings to understand the root cause and fix for this.

In a short term, the entire Scrum TEAM consisting of PO, Scrum master and development team will need to take a CALL on whether to keep the functionality as it is or discard it and come back to what was agreed at the beginning of the sprint.

Here you are considered as Product Owner. Product Owner should be easily approachable and most likely to be sitting at the same place where the team is located [collocation]. This will INCREASE the collaboration between team and product owner and reduce a great amount of time in clearing team doubts about user stories.

He should be very transparent with respect to goals, aspirations and discussions.

• Location: A Product Owner should meet the team very often and in a very respectful and transparent manner.
• Issue discovery: When the  team discovers any issue then they should immediately inform the Product Owner to take the necessary decisions. Therefore, a PO is an empowered person who can handle these situations diligently instead of cribbing or shouting on the team.
• Requirement Change: In such cases, PO should transparently talk to the team to explain the business need of this change and how it will help the customer. Needless to say, this discussion will need to be backed up with a correct business justification, value GENERATION, time estimates and see if it fits the current sprint or not.
• Motivation with realistic asks: It is important to remember that commitment towards amount of work in a sprint is a Scrum team’s area of ownership. No one can force Scrum team to pick up more than they can deliver but a PO should try to motivate the team by SHOWING them how they can improve their velocity or value generated. PO can also pitch in while prioritization discussions to help take up important asks first. 
• Communicating Vision: PO should regularly communicate their vision of PROVIDING value to the customer and how the user stories will help achieve those to scrum team. It helps them get aligned with the vision and become part of your journey.
• Meetings: PO should be part of sprint planning, backlog grooming, sprint REVIEW, sprint retrospective meetings for sure. Regarding Daily scrum, their presence is not mandatory because they can refer to the Information radiators to see if the value is being generated.  If a PO wants to attend daily scrum meeting then they are welcome to do so but should be in a passive mode.

• MANDATORY Attendees: Development team, Scrum Master and Product Owner
• Optional Attendees: Project Stakeholders
• When should review be done: The most common answer is to have review/demo at the end of the sprint. However, that works if the amount of user STORIES to be reviewed is small enough. For COMPLEX projects, where the stakes are high, it is recommended to have a regular cadence of review every week for the finished user stories. This reduces risk and allows the developer enough time to make corrections, if something is not found right in the review. For EXAMPLE, It is fine to have a regular cadence of doing TECHNICAL reviews every Tuesday at 3 PM and Demo of finished stories every Thursday at 11 AM in the morning. If there is nothing to be reviewed or demoed then that meeting can be cancelled.
• Duration: 45-60 minutes

Sprint is a time-boxed event that is for a FIXED duration of time to allow the SCRUM team to focus on delivering VALUE to the customer by solving important PROBLEMS. During this time, Scrum team follows SCRUM values and Agile principles and makes sure the team continues to make sustainable progress over a period of time aligned with planned value. Sprint can be of any duration from 1 week to 6 weeks but the most ideal duration is 2 to 4 weeks.

Once a sprint duration is finalized, then it remains unchanged for the CURRENT release.

There are many product development frameworks that embody the Agile Manifesto values and Principles from the more well known to specific, bespoke frameworks in a single organisation.  The more well-known frameworks and what they contribute to the Agile movement overall are:

• The Agile Project Framework (APF) – The APF is a development of the world’s first published ‘Managed RAD’ framework, DSDM, from the Agile Business Consortium, formerly the DSDM Consortium.

The APF is the only Agile framework to include advice and processes specifically about product development governance; aspects such as Product Vision, Objectives, expected Benefits, Business Case, management structure and communication plans.

Other Agile frameworks do not go into these details because they believe that organisations already have governance processes in place; for those organisations that do, the processes are not usually suitable for use in an Agile environment.

Similarly, the APF includes the most information about the processes required to RELEASE increments of the product into the live environment.

One of the APF phases, ‘Evolutionary Development’,  can be replaced with other Agile frameworks such as Scrum, Kanban or Lean Software Development.

• Kanban – the Kanban framework evolved from the visual board that represents product development flow from the Toyota PRODUCTION System; in Japanese the WORD is ‘kanban’ with a small ‘k’; the Kanban framework is usually spelt with a capital ’K’.

David Anderson developed the Kanban framework from the concept of a kanban adding required process management aspects.

The values that Kanban brings to the Agile community are:

• It can be introduced simply into an existing process; the existing process changes from a continual series of ‘Inspect and Adapt’ SESSIONS; there is no need for a large cultural change up-front.
• It introduces the concept of the ‘kanban board’ that shows product development flow through the development stages; sometimes known as a ‘Story Board’, ‘Sprint Board’ or ‘Team Board’.

• Introduces the concept of limiting the work in progress (WIP) for any column to keep the focus on a small subset of the required work and helping to identify development issues.
• eXtreme Programming (XP) – The XP framework development was led by Kent Beck during the Chrysler Comprehensive Compensation (C3) project.
  

XP focusses on software development techniques and as such contributes the following to the Agile community:

• User Stories – To avoid ‘Requirements Specifications’, early XP practitioners developed User Stories to define ‘requirements’ on 5x8 cards: 

“As a {role name}

I need to {name of business process}

So that {business reason for the business process need}”

• Pair Programming – ‘No line of code is written without 2 people looking at it’.  

This does not double the cost of software development because the reduction in rework needed when using pair programming more than compensates for the apparent extra cost.

• Test-Driven Development (TDD) – ‘No line of code is written without a coded test being written for it first’.

TDD is concerned with Unit Tests; other testing, such as system, integration and user testing is CARRIED out much as the same as in any other framework.

Just as with Pair Programming, above, the quality increase of first-pass coding dramatically reduces any necessary rework.

• Continuous Integration (CI) – With CI a complete build of the parts of the product so far built is done often, sometimes as often as when the source code for each new piece of functionality is checked-in to the source code repository.

CI allows for any integration errors being found as soon as practicable and they are fixed before further development continues.

• Refactoring – is a technique where the working source code for an object-oriented method/function is split into smaller, very focused and re-useable methods/functions.

Although there are significant costs to refactoring during the product development, the cost of the product maintenance is significantly reduced because the source code is easier to read.

There are not many implementations of XP in the world but, as you are probably aware, the above techniques developed by XP practitioners are used by practitioners in many other Agile frameworks.

• Lean Software Development (LSD) – LSD takes the principles of Lean Manufacturing and applies them to software development.

The concepts embodied in the LSD Principles can be used to enhance Agile Values and Principles:

• Eliminate waste
• Amplify learning
• Decide as late as possible
• Deliver as fast as possible
• Empower the team
• Build integrity in
• See the whole

Yes, and it may capture PROBABLE backlog items for next SPRINT, but the scope of next Sprint is deferred until Sprint Planning. In Scrum, each sprint delivers a potentially shippable product increment at the end of each Sprint. In Scrum, every Scrum event is an opportunity to Inspect and Adapt. In Sprint REVIEW, INSPECTING the product Increment provides insight and clarity. This newly IMPROVED knowledge is used to adapt the next steps i.e. find out what to do next.

It only lays out the initial known and best understood requirements. The product backlog is a living artifact that evolves and constantly changes to identify what the product needs to be appropriate, USEFUL and competitive. A well-prioritized product backlog not just makes iteration and release planning easier but ALSO reports all the things that the team PLANS to spend time on, as it should be transparent for both the development team and the STAKEHOLDERS.

They do not play an active ROLE within Scrum, they INFLUENCE it through other means. Product OWNER makes a DECISION based on the inputs received.

Sprint backlog.Team members are expected to update the sprint backlog at least once a day during the SCRUM sprint as new information is available. Most of the scrum teams will do this during the Daily Scrum. Scrum master ESTIMATES the amount of work remaining in the sprint each day and graphs the sprint burndown CHART. The sprint backlog is a plan with ample detail that changes in DEVELOPMENT can be understood in the Daily Scrum.

The Scrum team. The scrum team which INCLUDES PO, Scrum Master, and the development team decides the sprint LENGTH. The team during retrospective will inspect and adapt on the sprint length and arrive at an agreement. The scrum master acts as a facilitator to help the team arrive at an agreement and he/she will COME in only when the team is UNABLE to decide and helps to set the sprint length. Once decided, the duration of sprint usually remains the same throughout the PROJECT.

Scrum Team together negotiates and reaches an agreement. They may use Velocity as a STANDARD to calculate how much work they can take. Product OWNER optimizes the teams work by keeping the Product BACKLOG ordered. Only, the Development team can finalize how many Product backlog Items it can complete in the Sprint. The decision of finalizing the NUMBER of product backlog items is MADE by the Scrum team together. They collaboratively negotiate and reaches an agreement.

The value of the product backlog lies in transparency that permits the team MEMBERS to know what work needs to be DONE in order to produce a minimum viable product (MVP). Value is an estimated value based on assumptions. It has ALSO to be VALIDATED by releasing the increment to the customers. Scrum facilitates early validation.

It means that the team must have all the competencies to meet Sprint Goal as per DEFINITION of “Done”. Cross-functional teams can be inspected as a team of cross-functional members with domain and functional EXPERTISE. For INSTANCE, if one is DECLINING a sprint cycle, then members with STRONGER skills in a cross-functional team can connect and work with other team members to finish the sprint on time. Cross-functional teams are more productive than teams with the same skilled individuals working on related projects.

Scrum does not order when and how to release the product increment. The product OWNER decides whether to actually release the product or not once the increment is usable and meets the Scrum Team’s Definition of Done. Each increment should be RELEASED possibly with no WORK left undone. This implies that the product owner should be in a position to release a delivered increment INSTANTLY and with no further dependency on the development team.

Empiricism. 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. Transparency, INSPECTION, and Adaptation are the three pillars that uphold every IMPLEMENTATION of the empirical process control.

Every event in Scrum, besides the Sprint which is a container for the other events, is an opportunity to inspect and adapt. Sometimes, Sprint is referred to as just a TIME frame. It is not an event LIKE Scrum PLANNING, Scrum Review, Scrum RETROSPECTIVE, and Daily Scrum.