Explore topic-wise InterviewSolutions in .

No. The Sprint Goal gives some FLEXIBILITY to the Development Team. If the work turns out to be DIFFERENT than expected, the Development Team collaborates with the Product Owner to negotiate the scope of the Sprint BACKLOG within the Sprint. In that case, the development team discusses with the PO and reaches the CONCLUSION.

This indicates that the DEVELOPMENT team ADDED new work. The line indicating EFFORT remaining in the burndown graph varies from team to team and day to day. If more work items (user stories and issues) are added after the sprint started then this shows an UPWARD spike. The spike indicates added work and the Product Owner cannot add new work to Sprint BACKLOG without the consent of the Team.

No. After developing a product increment at the END of each sprint, a Sprint REVIEW meeting is held. The Sprint Review meeting provides a platform to the team MEMBERS to show what they accomplished during the sprint. Scrum EVENTS are time-boxed to eliminate waste and reduce risks. The team needs to address the root causes and ADHERE to the time-box.

The DEVELOPMENT TEAM should it TRANSPARENT that they cannot make a forecast with insufficient information, and negotiate with Product Owner on refining the stories to a Ready STATE. In scrum, each and every iteration starts with a sprint planning meeting. During this meeting, the PO and the team discuss which stories a team will handle that sprint. The Product Owner needs to help clarify the selected Product Backlog Items. Scrum Master can also coach the Product Owner on how to accomplish this viz. by having regular Backlog Refinement sessions. Later, the team can also discuss in Retrospective.

YES, the LENGTH of the sprint can be changed but it should be FIXED before starting the sprint. The product owner needs to ensure that the sprint is short ENOUGH to limit business risk and ALSO short enough so that the team can synchronize their development work with other business events. Finalized Sprint length cannot be longer than 4 weeks (1 month).

The PRODUCT OWNER only. A customer shouldn’t spend time detailing the product issues to the DEVELOPMENT team, this is the job of a product owner. The product owner is responsible for the PROJECT SUCCESS and is finally responding to the customers, team and to the company. He/she is the voice of the customer to the development team and ensures that all channels of communication are open and that project has ample amount of support needed to succeed.

No. The benefit of forming self-organizing teams is not that the team identifies some additional role within the scrum for its work that a manager has MISSED. Instead, it is that by enabling the team to self-organize, it is motivated to completely own the problem of performing the work at its best. In SHORT, a self-organizing team is a GROUP of motivated individuals who have the authority and ABILITY to take decisions and adjusting to changing demands quickly and EASILY working together towards a goal.

The development team should ask the executive to work with the PRODUCT Owner. The product owner is the voice of the EXECUTIVES in the PROCESS of COMMUNICATIVE discovery. How the feature is developed is up to the PO and the Scrum Team, and depends on the nature of the product under deployment and the availability of the stakeholders. The product owner REPRESENTS the needs and desires of the executive to the development team and prioritizes their work that helps the team to do it in the right way.

It is not an APPROPRIATE GOAL since Sprint Goal should be about EXPECTED BUSINESS value.

One. Multiple Scrum teams, each with a Scrum Master can drag their work items from a single product BACKLOG and the presence of the product owners depend on the NUMBER of product backlogs. A CERTAIN project should have only one Product Backlog and one Product Backlog should only have one Product Owner OTHERWISE, it would be difficult to deliver the product.

There should be one Product Backlog and one Product Owner. Many SCRUM teams, each with a Scrum Master can pull work items from a single product backlog and the presence of the product OWNERS depend on the number of product backlogs. A CERTAIN project should have only one Product Backlog and one Product Backlog should only have one Product Owner otherwise, it WOULD be difficult to DELIVER the product.

Product OWNER.The Sprint can be called off before ending up the Sprint time-box. Only the Product Owner has the authority to cancel a Sprint. This happens when the Product Owner realizes that it makes no sense to FINISH the Sprint, as defined in Sprint Backlog. The PO may cancel the sprint under the influence of any Stakeholder, the DEVELOPMENT team, or the Scrum MASTER.

15 minutes. 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.

TIMEBOXING is the process of allotting a fixed and maximum unit of time for an activity. That allotted unit of time is a timebox. The goal of timeboxing is to define and limit the amount of time dedicated to an activity. The time-box SET for the Sprints should not be longer than one month and should be selected considering DIFFERENT factors such as the risk and DELIVERY time.

Refer the representative to the PRODUCT Owner to discuss it. If the CUSTOMER is asking for ADDING an item to an ongoing Sprint, adding it in collaboration with the Product Owner is the best-suited way to add any NEW item to the Sprint. Because adding a new item to the product backlog without asking the product owner may result in REMOVING a transparency and undermining trust with the Product Owner.

No. Single members MIGHT handle most or all of the work of a particular Sprint BACKLOG item, but RESPONSIBILITY remains for the WHOLE team. When each member of the Development team owns the Sprint Backlog items, the team will DERAIL from the core-value of Agile which is nothing but the ‘Collaboration’.

It is a good PRACTICE, KEEPING in mind that market reception is the BEST measure of VALUE. INDICATIONS of value on Product Backlog are useful but are only a prediction until validated against users and market.

The OWNER of a product is not only accountable for the development and release of a product, but also the cost of maintaining and operating the product. If a person 'owns' the product, he/she can be EXPECTED to be responsible for the COMPLETE lifecycle of a product.

Whatever is the most appropriate for the PRODUCT Owner to achieve the product's goals and to optimize the value received. The Product Owner is responsible for ordering the items in the Product Backlog to best achieve goals and missions, thereby optimizing the value of the WORK the DEVELOPMENT Team performs. How this is DONE, and what value means, may VARY widely across the organizations.

By releasing often, and updating key performance indicators (KPIs) on value after every release and feeding this information BACK into work on the PRODUCT Backlog. Scrum TEAMS deliver PRODUCTS iteratively and incrementally, maximizing opportunities for feedback. If a product isn't released, the opportunity to capture user and market feedback is lost. By releasing every increment and updating the Key Performance Indicators (KPIs) on value after every release can help to KNOW the product built through Scrum is successful.

No. A Product OWNER engages actively and REGULARLY with the STAKEHOLDERS. However, to limit the DISTURBANCE to the development progress and KEEP a focus of the Development team high, the key Stakeholders are allowed to take part only in the Sprint Review meeting. However, any Scrum team member can interact with them at any time.

There are no such pre-conditions. Sprint Planning serves to plan the work to be performed in the Sprint. This plan is created by the COLLABORATIVE work of the entire SCRUM Team. Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. What can be achieved in this time-box may be INFLUENCED by additional practices that are HOWEVER not PRESCRIBED by Scrum.

No. In Scrum, Product Owner takes care of the Product Value in order to GENERATE, deliver, and maintain a successful product. Value is likely to vary ACROSS the products and organizations. The value of the product DEPENDS on the CONTEXT of the product which you are developing.

RELEASE an Increment to the market to learn about the business assumptions built into the product. 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. The Product Owner drives iterative DEVELOPMENT from an exploratory attitude, aiming at incremental progress through CONTINUING discovery and validated learning.

Re-work the selected Product Backlog items with the DEVELOPMENT Team to meet the Sprint Goal. During the Sprint scope may be CLARIFIED and re-negotiated between the Product OWNER and Development Team as more is learned. The development team looks to the product owner for product backlog, for alignment and direction on the delivery of VALUE through the sprint goal achievement through the backlog implementation. The backlog can be changed to achieve the Sprint goal, but PO is responsible for value DELIVERED through the implementation of backlog to achieve a sprint goal.

Firstly, it assures the Increment REVIEWED at the Sprint review is usable so the PRODUCT Owner MAY choose to RELEASE it. Secondly, it creates transparency regarding progress within the Scrum Team. All Scrum Team members must have a shared understanding of what it means for work to  complete, to ensure transparency. This is the DEFINITION of "Done" for the Scrum Team and is used to assess when work is complete on the product Increment. The Increment reviewed at the Sprint Review must be usable, so a Product Owner may choose to immediately release it.

No. The ENTIRE organization MUST always respect a PRODUCT Owner's decisions. For the Product Owner to succeed, the entire organization must respect his or her decisions. No ONE is allowed to tell the Development Team to work from a different set of REQUIREMENTS, and the Development Team isn't allowed to act on what anyone else says. The PO can remove the product backlog items if he/she feels that is not a high priority one. Anyone can add an item to the product backlog. But, it is the PO who decides what happens to the PBI.

The Product OWNER and the Development Team. During the Sprint, the scope may be clarified and renegotiated between the Product Owner and Development Team as more is learned. As ISSUES EMERGE, changes can be made to the sprint backlog to accomplish the Sprint GOAL. The Development Team will then re-negotiate with the Product Owner REGARDING the Sprint Backlog. Although the Sprint Goal is fixed during the Sprint, the Sprint Backlog is not.

INFORM the Product Owner so he/she can work with the CEO. The items selected for a Sprint have been selected as most VALUABLE with the Product Owner. The items serve the Sprint's GOAL. No changes should be made that endanger the Sprint Goal. No ONE external to the Scrum Team can force changes on the Development Team (Sprint BACKLOG) and the Product Owner (Product Backlog).

No. The product increment should be USABLE and releasable at the end of every Sprint, but it does not have to be released. In Scrum, it is not mandatory to release each increment WITHOUT accepting the acceptance criteria. The developed increments should have a value ACCORDING to the customer’s needs. In short, you can say that it should be usable and releasable at the end of every Sprint without releasing to the PRODUCTION.

All DEVELOPMENT Teams must have a definition of "done" that makes their combined WORK potentially releasable. Each Scrum team consists of its own ‘Definition of Done’. Definition of Done defines the acceptance criteria across all User STORIES. Scrum requires an INCREMENT to be releasable. This is an Increment of product. Many teams working on a single product are expected to deliver the QUALITY of work.

It can change. The Sprint BACKLOG makes VISIBLE all of the work that the Development TEAM identifies as necessary to meet the Sprint Goal. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog EMERGES during the Sprint. If the work appears to be different than expected, the dev team COLLABORATE with the PO to negotiate the scope of the Sprint Backlog within the Sprint and adds more PBIs related to the current Sprint if necessary.

WITHOUT a new vocabulary as a reminder for the CHANGE, very little change may actually happen. Also, the organization may not understand what has changed with Scrum and the benefits of Scrum may be lost.

Scrum adoption is good, but this massive shift needs complete dedication. The organizations that are implementing the Scrum practices every day can be successful in Scrum adoption. If Scrum is implemented with all the team members on a daily basis can increase the collaboration and a quick product delivery. So, it is recommended to implement only Scrum methodology without CLUBBING any other methodology as it can be APPLIED to any complex project and will meet the project deadlines within a timeline, making the customer HAPPY!

NEVER. All Sprint Backlog Items are "owned" by the entire Development Team, even though each one MAY be done by an individual development team member. Sprint Backlog and all of its items are collectively owned by the Development Team. No individual team member can claim OWNERSHIP over an item as this would block COMMUNICATION and collaboration among the team members.

No. ONE product has one Product Backlog, REGARDLESS of how MANY TEAMS are working on that project. It is easy for the Development teams to coordinate with other teams if one product backlog is followed THROUGHOUT the project.

This typically happens when the Sprint Goal becomes OBSOLETE. A Sprint can be cancelled before the Sprint time-box is over. A Sprint WOULD be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions CHANGE. The abnormal termination might also occur if the team gets into the Sprint partway and finds that the WORK is going to consume too much time than expected in sprint planning.

Ideally, the TEAM should immediately raise the issue to the Scrum Master as an impediment. Scrum Master is responsible to take care of these kinds of problems, or impediments that stop the dev team from achieving the Sprint Goal and facilitate a team’s optimum performance. But, it is the responsibility of the team to communicate with the Scrum Master about what impediments are obstructing them. This communication occurs EVERY day in the DAILY Scrum and the MAIN purpose of it is to raise any impediments and refine the PLAN to meet the Sprint Goal.

Bill Wake has given us the mnemonic INVEST which HELP us in writing a well-formed User Story.

Splitting a story is not an easy task.

Let us first discuss different techniques on how to split a user story.

• Split by user roles-Administrators interact with the system in a different way than users. It a very good way of splitting the user stories by user roles.
• Split by capabilities offered.-Capabilities example like sorting and searching. Further sorting and searching may further split into different user stories.
• Split by user personas -Even in the same role, users interact with the system in various different ways. A handicapped person interacts in a different way, a casual user in a different way as he needs intuitive things, a POWER user needs lots of short cuts, etc.
• Split by target device- User can interact with our system not only using a standard computer but also using mobile, ipad etc.So this is also a good way of splitting a user story.

For DETAILED INFORMATION check my blog below.

How to Write A Well-Formed User Story 

These charts help to keep track of the progress of the sprint. Burn up charts indicates the amount of work completed in the sprint and the burndown chart indicates the amount of work remaining in the sprint

The Product Owner determines the amount of remaining work and compares it to the remaining work of the previous Sprints and forecasts the completion date of the project.

In the Burn-Down chart, the vertical axis (remaining work) shows the amount of work (which is a sum of all the estimates for each item in the Product Backlog), and the horizontal axis shows the amount of time PASSED from the beginning of the project or the number of Sprints passed.

We USUALLY add another line to present the uniform distribution of the volume of the work ACROSS the initially estimated number of sprints. This line acts as our planned progress and will be used to compare to our actual values.

In the above chart, we can expect the project to be completed earlier than initially planned.

In the Burn-Up chart, the vertical axis is the amount of work and is measured in units or story points, and the horizontal axis is time, usually measured in days.

Each day you can see the amount of work completed and the total amount of work. The DISTANCE between the two lines is thus the amount of work remaining. When the two lines meet, the project will be complete. This is a powerful measure of how CLOSE you are to completion of the project.

Ron Jeffries says: In Agile, the design must simply start simple and GROW up. The way to do this is refactoring.

Refactoring refers to changing the structure but not the behavior of the code. For Example: Suppose in the code base we have TWO methods and each has 3 identical statements. These statements can be extracted from this code and put it into some new method and both these methods can call the new method. This refactoring slightly improves the readability and maintainability of the program as the DUPLICATED code is moved to a new place. There are so many tools available with which you can run in your code base and it will help you in finding out the duplicity of code. In this way, the structure of the code is changed but not the behavior.

Refactoring is not only CRUCIAL to TDD but it also helps prevent code rot. Code rot is the typical syndrome in which a product is released its code is allowed to decay after a few years then an entire rewrite is required. By constantly refactoring and fixing small problems before they become big problems, we can keep our applications rot free.

When a refactoring opportunity is identified have a conversation with product owners and scrum master and get that added as part of a product backlog. At the end of 2-3-hour long programming session spend at least 20-30 minutes in cleaning up something you noticed as you were touching or looking at EXISTING code.

Always discuss refactoring in your next retrospection inkling your product owner.

My suggestion is to include them as part of your sprint planning and all team members should collectively work on that.

Every team will go through 4 stages of group development which is Forming, Storming, Norming and Performing.

• Forming- Most team members are new, polite and humble in this stage also the roles and responsibilities are not clear to the team.
• Storming- This is a SITUATION where there is a clash between a few team members due to their roles and responsibilities, their work or some other issues. Retrospection there will be a huge qiosk. EVERYBODY has their own working style due to which there will be a conflict between many team members due to different SORTS of reasons. This is where the team fails.
• Norming- In this phase of development people start resolving their issues, differences and start appreciating their colleagues for the work. This is a very GOOD stage as the team is moving towards the goal of self-organization.
• Performing- In this phase, the development team has one sprint goal and they all work towards it, this is where hard work pays and the project is released with the best quality. It is easy to be part of such a team where any disruption will not alter their sprint goal.
• The same is depicted in the FIGURE below.

Yes definitely there can be multiple teams for the same project. For example, the UI team, Service layer team, etc. The team can be feature teams or component teams and can be geographically distributed.

Scrum Master role is very challenging in this type of multi-team handling collaboration and coordination. The reason is the time gap between two different teams which makes it even more challenging.

But there are many ways by which it can be handled. There are 2 suggested frameworks available

• LESS-Large Scale Scrum

The idea is to manage the complexity of large-scale development with ease.

It recommends multiple teams with the same product owner with multiple sprint backlogs but with one product backlog.

Process-wise LeSS is same as that of scrum but with slight modification. Sprint planning is split into two parts. One planning consists of representatives from all the teams where the team decides about “WHAT” the Product Backlog items to be built in the next sprint. The second planning meeting will be done by the individual team about how the PBI needs to be built.

The end of the sprint should ALSO be synchronized. The sprint review meeting should be held in common with all the business leaders and team and the stakeholders.

Similarly, retrospection can be a help in 2 parts. One which is common to all the whole project team and one with the individual team so that the focus can be on individual team issues and work towards them to resolve them.

• SaFe- Scaled Agile framework.

Refer to interview questions Article? Question 17.

When to use which framework?

1. When you need to coordinate with hundreds or thousands of people in a big organization. SaFe is the recommended framework.
2. When the transition from the Component level team to feature level team is difficult.

SaFe makes it easy even to handle the component level team through RTE and Program Board.

How to coordinate?

Scrum of Scrums: This is one of the meetings which happens daily with all the scrum masters and CHIEF Product Owner can facilitate it. It is the same as that of daily scrum but the focus is on a team level.

Each team sends out one member to participate and answer the following questions:

• What did the team finish/achieved?
• What does the team plan to finish today?
• Are there any impediments? If yes how we can resolve them.
• Common Retrospectives.
• Common Sprint Planning
• Common sprint reviews

Sprint Scheduling-All the teams can start and ends at the same time. But there can be a difference in that also. It makes our coordination and communication easy. They can also have 1-2 days gap in STARTING the next sprint which is good for product owner not to attend all the meetings

Effort Estimations: A very important aspect of Scrum Planning. In the CASE of the same technique of effort, estimation should be used like Planning poker, shirt size estimation, etc. If story points are used all teams have to agree on the same metric and a common scale to use.

There are still a few CHALLENGES which the Scrum team face during the development phase.

• Non-availability of Product Owner at the site.
• During the development, some field issues or high priority bugs come up.
• Difficult to change the mindset of management from the traditional model to Agile.
• Some development efforts don’t EASILY fit into a time-boxed sprint. Therefore, Scrum doesn’t work for me. This is a real problem. Several kinds of development resist being meaningfully squeezed into standard size SPRINTS. Here’s a partial list:

• New system architecture
• New complex user interface design
• Database ETL requiring extract, cleanse, transform, stage, and present data

• Developers accustomed to working AUTONOMOUSLY may find that Scrum is unnecessary and slows them down.
• DISTRIBUTED team-Communication is the core issue among distributed teams. Different time zones and conflicting working hours may impair overall effectiveness, and collaboration may be difficult in some cases.

Though there are so many challenges, there are ways to handle each and every situation and deliver a quality product with customer satisfaction.

The selection of the iteration length should be guided by the following factors:

• The length of the release being worked on.

It means that if the team is working towards a release which is three months away, one-month iteration will give only 2 opportunities to gather feedback which in most cases insufficient.

The general rule of thumb is that any project will benefit from at least 4-5 opportunities to get feedback. So, if a project overall duration is 5 months above then it is worth to consider 4-week iteration. Otherwise, 2-3 WEEKS iteration is a good choice.

• The amount of uncertainty.

When there is a great amount of uncertainty about the work to be done then short iterations will allow to get more frequent feedback and BUILT the correct product.

• The ease of getting feedback.

Choose an iteration to maximize the value of feedback that can be received from inside and outside the organization.

• How long priorities can remain unchanged.

If there are chances of change in priorities then it better to go for short iterations. If we are going with long iterations and there is some change in requirement then we need to wait for 4 weeks to implement them.

• The overhead of iterating.

There is a cost associated with each iteration as each iteration should be fully regression tested. If this is costly, then the team may prefer 4-week duration

• How soon a feeling of URGENCY is established.

As long as the end date of a project is far in the future, we don’t feel pressure and work leisurely. The point is not to put the team under more pressure. Rather, it is to take the total amount of stress they NORMALLY feel and distribute it evenly across a suitable long iteration.

This is a very common scenario seen in the projects which are using Scrum Approach. The team should always be prepared for that. But try to have a GOOD conversation with the Product owner to not include in the current sprint and deferred to the next sprint. Changes in requirements sometimes taken as FEEDBACK from the customer so that the product can be improved. We should be ready to embrace this change.

As a tester, they should TAKE the generic approach by writing the generic test cases (Login screen, user credentials). Till the requirements are stable, try to wait if you are planning to automate the test cases.

As a developer, the same approach can be used where chances of changes are minimal. Try to code using design patterns and oops concepts (Components or PACKAGE independent of each other), so that change in ONE component makes minimal changes in another.

  There are many lists of coaching techniques; the following is fairly a fairly COMPREHENSIVE list but exhaustive:

• The 5-minute pre-session Check-In – Let your clients complete a short questionnaire before each coaching session. This helps both you and your clients to recognize their progress and SUCCESS since the last session.  You’ll find out if there were roadblocks and what they’ve been struggling with. It shows you what bothers them most at the moment and what they want to focus on during their next session.
• Use the SMART goal setting technique in your coaching – SMART goal setting stands for Specific, Measurable, Attainable, Relevant and Time-Based.

This technique brings a clear structure into goals.  Each goal or MILESTONE comes with clear and verifiable elements instead of vague resolutions.  The broad goal of “I want to grow my business” will be described in much more detailed and action-oriented steps by the client. The SMART goal could be: “I will WIN five new clients for my business this month by asking for referrals, creating two useful blog articles and social media networking”. 

• Let clients write down and share the gold nuggets after each session – Encourage your clients to share their gold nuggets from each session with you; it leaves them with a clear picture of how much value they received from your coaching. 

It’s easy to help them get going with just a few simple questions like: “What was the most valuable takeaway from this session?”. This coaching technique helps you to find out the client’s “A-ha” moments and to avoid misunderstandings. 

If all these notes are organized in a shared stream that is accessible to both you and the client you can reread and recap these nuggets any time at later stages during the process.

• Ask open-ended questions – Open-ended questions allow your clients to include more information, including feelings, attitudes, and understanding of the subject. This allows the coach to better access the clients’ true thoughts and feelings on the topic. 
• Use the power of writing – Writing down plans and goals is the first step towards making them a reality. It commits your clients to act, especially when they are shared and recorded with someone else (like with you – their coach). 

Writing enhances your client’s power of observation and focuses during a change or development process. 

A study with two groups has shown that people who write down goals and make a weekly progress report achieved their goals at a rate of 76%, whereas the participants of the group who didn’t write anything down achieved their goals at a rate of only 36%. 

• Be fully present and focused – Take two minutes for yourself and breathe calmly before each session.  Once your meeting has started, try to avoid distractions and give your clients undivided attention. Show your genuine interest and that you really care. This may sound self-evident but is an important step toward BUILDING trust and a meaningful coaching relationship.
• Follow-Up with the client – Use regular questionnaires where clients share their progress, experiences, success or challenges they might be facing. 

This ongoing feedback as a follow-up between sessions is a perfect way to monitor and evaluate the effectiveness of the coaching. It shows your clients that you really care about their progress and gives them the feeling they’re not alone with their challenges.

• The coaching journal of progress – A regular progress and reflection journal helps your clients to develop and gain self-awareness. 

A coaching journal is similar to the ongoing feedback described before. Your clients can write down their emotions, experiences, observations, challenges, success, thoughts, and feelings. They don’t have to wait until the next sessions which might be in a week or two but can share what’s on their mind right at the moment where it happens.

A shared journal gives your clients the feeling that you’re always there for them and “listening” without the need for your presence. They can write whenever they feel like it; at night, in the morning, during the day, at the train station on the way to their workplace or while waiting for the doctor.

A coaching journal gives them the ability to focus on themselves only without any time pressure or distractions. Once written down they can always reread and recap prior entries at a later stage of their process. Once these thoughts are shared with you you’ll gain invaluable information that will take your coaching and mentoring to the next level. 

• Homework assignment to strengthen accountability – No matter if you call it homework, worksheet, questionnaire or action item. They all support the work you’ve been doing within a coaching session. They help clients to reflect, act and achieve necessary milestones towards their bigger goal. 

Homework helps to see if and how the plans from each session are being applied; it helps clients to keep the focus on their plans, ideas, and goals.

1. The GROW model – The GROW model is a simple method for goal setting and problem-solving in coaching. It includes 4 stages:
2. G for Goal: The goal is what the client wants to accomplish. It should be defined as clearly as possible. You could combine it with the SMART method described earlier
3. R for Reality: That is the status quo, where our client is right now.  The client describes his/her current situation and how far she is away from her goal
4. O for Obstacles and Options: What are the obstacles (roadblocks) that keep your client from achieving the goal? Once these obstacles are identified you can find ways to overcome them – the options.
5. W for Way forward: Once identified the options need to be converted into action steps that will take your client to accomplish his/her goal.
6. A Shared To-Do list – The client commits to various action steps and plans during the coaching sessions.  Once they write down and share these ‘to-dos’ with you they actually put them into existence; they become like a contract between you and the client and strengthens their accountability. 

Another benefit is that both of you know what is getting done and what isn’t at any moment during the process. You immediately see where they procrastinate or struggle and when your support is needed.  The shared to-do list helps to set priorities, achieve milestones faster and keep track of the small wins during a coaching process.

• “My goal is achieved” – It is a great thought experiment if you ask your client to exactly describe a perfect day once the desired goal is achieved. 

It shouldn’t be just a vague description but a whole day from start to finish:

• How would he/she feel after waking up? 
• What would he/she do? 
• How would he/she feel? 

This technique will encourage the client to use his/her positive imagination and visualize what he/she truly desires. 

Afterward, you can work together to get the actual steps to that “miracle” where the goal is achieved.

• Use every session to become a better coach – Every single session offers you the chance to become a better coach.  Take five minutes immediately after your client left and write down some thoughts; you can:
• Track reactions to questions of a client
• Think about methods and techniques you used in the session and how  they worked
• Reflect upon the overall success of the session
• Think about something you would do differently if you could “replay” the session?

The major difference between Sprint and iteration are:

1. Sprint is used for time boxed duration for project delivery in Scrum
2. Iteration is a generic term that is used to define any iterative PROCESS to create the increment, get it reviewed, release it, take feedback and start the NEXT iteration
3. When it comes to official terms, then XTREME programming CALLS them ITERATIONS and Scrum calls them sprints.

User story is a story about a user and their experience with a particular FEATURE of the product. As a result, user story is a representation of a requirement in a story form as expected by the end customer. 

In order to create a user story, the technique of “As a ___, I want___ so that I can ___.” Is best suited.

Because it covers the role of the user, actions they want to perform and what expectations they have with the results of those actions.

Once we have the user story available then INVEST Principle can be used to review it.

Example: As a user, I want to login to the screen so that I can book the tickets.

The test for determining whether or not a story is well understood and ready for the team to begin working on it is the INVEST ACRONYM:

• I – Independent
• N – Negotiable
• V – Valuable
• E – Estimable
• S – Small
• T – Testable

Scrum is best suited for all organizations of any shape or size. Small organizations are most suited to TAKE an advantage of the Agile methodology because they do not have INERTIA and long processes to HOLD them back or INITIATE a change. So small organizations can adopt Agile and Scrum faster.

It is a tricky question. There is no specific answer to this question rather there are few questions that you should ask yourself to MEASURE how mature your team is with respect to the Scrum process.

• Is your team self-organized?
• Is your customer satisfied with your deliveries?
• How MANY FIELD issues after installation of the software?
• Is the software delivered on time?
• What kind of behavioural improvement is seen after applying scrum process?
• Are people transparent and sharing their feedback openly?
• Are people ready to take feedback from the customers and ready for any continuous improvement?
• Is the cycle time IMPROVING as you progress in scrum?
• Do you have a predictable delivery or velocity?
• How did the scrum affect the speed of the delivery?
• What kind of outcomes you are able to predict because of Scrum?

It is not COMPULSORY to measure each and every point but the interviewer is expecting you to give him a few examples to measure. The customer value and speed of delivery are the two pillars of maturity in your process.