Scrum Interview Questions Agile Management

One of the core principles of Scrum is working software over software documentation. But it doesn’t mean there will not be any documentation but yes, they need to keep at its minimum. It is more important to think about users’ goals than to list the attributes of a solution.

• In Scrum, we consider the requirements as User Stories. They are similar to the use case scenario. But use cases till tend to be larger than single story and can be more prone to containing embedded assumptions about user interface.
• Use cases are much more complete than user stories. Use cases are designed to be permanent artifacts of the development process while user stories are more transient and not intended to outlive the iteration in which they are developed.
• In the requirement documents use cases are written so that developers and customers can discuss them and agree to them. User stories are written to facilitate release planning and to serve as reminders to fill in requirements details with conversations.
• User stories emphasize verbal communication. Written language is often very imprecise, and there’s no guarantee that a customer and developer will interpret a statement in the same way.
• Traditional documents are very tiring, tedious, error prone and time consuming compared to user stories.
• In this case, time was wasted writing the three-fourths of the document that the team won't have time to develop, and more time will be wasted as the developers, analysts, and customer iterate over which functionality can be developed in time. With stories, an estimate is associated with each story immediately. The customer knows the velocity of the team and the cost of each story.

• Sprint Planning Meeting: 
  • Attendees: Development team, Scrum Master, and Product Owner
  • When: At the beginning of the sprint.
  • Duration: Approx 120 min for a 2-week iteration
  • Purpose: Product owner comes with the prioritized backlog and then the Scrum Team plans the items they are going to deliver in the Sprint and the way they will deliver them, estimate them, break into tasks.

There are two defined artifacts of sprint planning.

1. Sprint Goal-The sprint goal should be a short description of what the team plans to achieve during the sprint. It is written collaboratively by the team and the product owner.

Example-Implement login functionality of the website.

2. Sprint backlog-The sprint backlog is the output of the sprint planning. A sprint backlog is a list of the product backlog items the team commits to delivering plus the list of tasks necessary to delivering those product backlog items. Each task on the sprint backlog is also usually estimated.

3. Iteration planning -Iteration is a more generic term with respect to the Agile. It is used for a single development cycle and is used for Iterative and Incremental process. Sprint is Scrum specific hence sprint is an iteration but not all forms of iterations are sprint.

• Epic -An epic captures a large body of work. It is essentially a large user story that can be broken down into a number of smaller stories. It may take several sprints to complete an epic. 
• User Story- A story or user story is a software system requirement that is expressed in a few short sentences, ideally using non-technical language. It is generally estimated in story points.
• Task- A task is a unit of work contained within a story. It is estimated in hours.

An example is given below.

TDD is defined as programming practice which starts before the development phase starts, unlike Traditional testing. It instructs developers to write new code only if an automated test has failed. The primary goal of TDD is to make the code clearer, simple and bug-free.

TDD is an iterative development process. Each iteration starts with a set of tests written for a new piece of functionality. These tests are supposed to fail during the start of iteration as there will be no application code corresponding to the tests. In the next phase of the iteration, Application code is written with an intention to pass all the tests written earlier in the iteration. Once the application code is ready tests are run.

Any failures in the test run are marked and more Application code is written/re-factored to make these tests pass. Once application code is added/re-factored the tests are run again. This cycle keeps on happening until all the tests pass. Once all the tests pass, we can be sure that all the features for which tests were written have been developed.

Following steps define how to perform TDD test

• Add a test.
• Run all tests and see if any new test fails.
• Write some code.
• Run tests and Refactor code.
• Repeat.

Benefits of TDD

• The unit test proves that the code actually works
• Can drive the design of the program
• Refactoring allows improving the design of the code
• Low-Level regression test suite
• Test first reduce the cost of the bugs

BDD is an extension of TDD. The major difference between TDD and BDD are:

• Tests are written in plain descriptive English type grammar
• Tests are explained as the behavior of an application and are more user-focused
• Using examples to clarify requirements

This difference brings in the need to have a language which can define, in an understandable format.

Features of BDD

• Shifting from thinking in “tests” to thinking in “behavior”
• Collaboration between Business stakeholders, Business Analysts, QA Team and developers
• Ubiquitous language, it is easy to describe
• Driven by Business Value
• Extends Test Driven Development (TDD) by utilizing natural language that non-technical stakeholders can understand
• BDD frameworks such as Cucumber or JBehave are an enabler, acting as a “bridge” between Business & Technical Language

Example:

Scenario: Duplicate email Where someone tries to create an account for an email address that already exists.

Given I have chosen to sign up But I enter an email address that has already registered Then I should be told that the email is already registered And I should be offered the option to recover my password

Now after a look at the above example code, anybody can understand the workings of the test and what it is intended to do. It gives an unexpected powerful impact by enabling people to visualize the system before it has been built. Any of the business users would read and understand the test and able to give you the feedback that whether it reflects their understanding of what the system should do, and it can even lead to thinking of other scenarios that need to be considered too.

Advantages of BDD:

• Writing BDD tests in an omnipresent language, a language structured around the domain model and widely used by all team members comprising of developers, testers, BAs, and customers.
• Connecting technical with nontechnical members of a software team.
• Allowing direct interaction with the developer’s code, but BDD tests are written in a language which can also be made out by business stakeholders.
•  Last but not least, acceptance tests can be executed automatically, while it is performed manually by business stakeholders.

The four values of Scrum as per the Scrum Guide are:

• Individuals and interactions over processes and tools

Valuing people more than the processes and tools is the main aim of Scrum. Communication is an example of valuing individuals versus process. It is the people who respond to business needs and drive the development process. Daily Scrum meeting and Retrospection is an example of this where each individual will get to interact with the team and leaders directly.

• Working software over comprehensive documentation

Historically, an enormous amount of time is spent on documentation and was one of the biggest causes of delays in product development and delivery which indirectly leads to customer dissatisfaction. It is a myth that Scrum doesn’t support documentation rather it streamlined the process in such a way which gives the developer an opportunity to work on what is needed and deliver the best quality software which leads to customer satisfaction. Agile documents requirements as user stories, which are sufficient for a software developer to begin the task of building a new function.

The Agile Manifesto values documentation, but it values working software more.

• Customer collaboration over contract negotiation

In the Scrum process, the customer has involved even before the project starts (Iteration planning), during the project execution which is sprint review. With this customer collaboration during the entire process, the development phase is quite easy and expected to meet the customer needs. With development models such as Waterfall, customers negotiate the requirements for the product, often in great detail, prior to any work starting which means that requirements are completely frozen and no scope of changing them in between.

• Responding to change over following a plan

With short sprint cycles, the customer change in requirements can be incorporated easily in the next iteration whereas traditional methods the incorporation of changes in the middle is very expensive.

Agile’ s view is that changes always improve a project; changes provide additional value.

Traditional waterfall model treats Analysis, Design, Coding and testing as discrete phases of a software project.

Quality Suffers:

First, the project runs out of money until it reached the last phase. This means that a good project tends to cut on the testing phase and the quality suffers.

Poor visibility:

Secondly, because working software isn't produced until the end of the project, you never really know where you are on a Waterfall project. That last 20% of the project always seems to take 80% of the time.

Too risky:

Thirdly you've got schedule risk because you never know if you are going to make it until the end. You've got technical risk because you don't actually get to test your design or architecture until late in the project. And you've got product risk because don't even know if you are building the right until it's too late to make any changes.

Can’t make changes in the middle:

It’s not easy to make any changes in the middle because the architecture and all technical aspects are already closed before the development phase. It is very costly to do those changes in the middle.

The Agile Approach:

Instead of treating these fixed stages Agilists believe these are continuous activities.

By doing them continuously:

• Quality improves because testing starts from day one.
• Visibility improves because you are 1/2 way through the project when you have built 1/2 the features.
• Risk is reduced because you are getting feedback early, and
• Customers are happy because they can make changes without paying exorbitant costs.

Definition of Ready: A sprint is a time-boxed development cycle in which items need to be pulled from the prioritized backlog. However, it is very important that the items (User Story) should be in “Ready state”. Pulling unfinished or unrefined user story will make the current sprint delay its deliverables as well as developer will also not be able to develop the expected functionality.

“Ready” State is clearly depicted in the below diagram.

Definition of Ready is focused on the User Story level characteristics whereas Definition of Ready on Sprint and Release level.

Definition of Done: It represents the acceptance criteria for the Sprint. This list is prepared in discussion/agreement with the Product Owner and Development team on what needs to be completed for user story—it is often standardized across the company in order to deliver consistent product quality.

Sample of Definition of Done is shown below. As per project needs, this can be tweaked.

• Test conditions are written where beneficial to a story
• Unit tests written (where crucial ) and passing
• Acceptance tests written, executed, and passing
• Functional testing complete
• System testing and bug fixing for functionality implemented
• Test cases are written and passing with expected results
• Regression tested where appropriate
• Code complete
• Code committed

Scrum board is highly recommended in the daily scrum meeting.

It gives better visibility not only to the team but other stakeholders too. In case somebody missed the daily scrum, a meeting can quickly go through the scrum board and gather updates from there. It is recommended that scrum board not only has the data of the sprint progress but it should also have sprint burndown chart also so that the team will have updates on the health of the sprint. On top of the board, the Goal of the sprint should also be mentioned along with the Definition of Done list.

There have been continuous advancements in software development technologies. When talking about software development methods one can simply not ignore the role that testing plays in software development. Therefore, in order to maintain pace with the latest software development technologies testing needs to be done faster than development.

Imagine you are building a big Software-as-a-Service product like Salesforce. The product has 1,000 features, and you also have to release a new feature every other month to keep up with the competition. Now imagine that you have to test that product, check if new features have not affected old features and every feature is working fine. All 1000 of them. Now imagine that you have to test the whole software within a week.

Not possible, right? That’s what enterprise developers thought before automating the process of testing.

Sprint is generally for 2-3 weeks. In that case, to test the whole software is not easy so recommended way is to automation which drastically reduces the time of testing and every sprint delivers the best quality software.

• When the same test case is to be repeated;
• When the test cases are very tedious and cannot be performed manually;
• If you have to run the test cases with different data and conditions several times;
• When the same test cases are to be executed with different user sets;
• If saving time is on your top priority; or
• When test cases need to be executed with various browsers and environments.

Pair programming the term derived from Extreme Programming. Pair programming is a style of programming in which two programmers work side-by-side at one computer, sharing one screen, keyboard and mouse, continuously collaborating on the same design, algorithm, code or test.

One programmer, termed as the driver, has control of the keyboard/mouse and actively implements the code or writes a test. The other programmer, termed as the navigator, continuously observes the work of the driver to identify defects and also thinks strategically about the direction of the work.

When necessary, the two programmers brainstorm on any challenging problem. The two programmers periodically switch roles and work together as equals to develop software.

Pair programming is much more effective as compared to code reviews. For code review, the code needs to be completed, but in programming in pairs leads to correct the code instantly without any waiting period. Pair programming is much more efficient as in code review it could be possible that the programmer might not be around. Fewer chances of bugs being corrected.

Benefits of Pair programming

• Fewer defects
• Better decisions
• Higher productivity
• Developers confidence
• Knowledge sharing
• Learning
• Team building

Testing is iterative and sprints based as depicted in the diagram given below:

Story points are a relative measure of the size of a user story. A user story estimated as ten story points is twice as big, complex or risky as a story estimated as five story points.

A ten-story point is similarly half as big, complex or risky as a twenty-story point story. What matters are relative values assigned to different stories. Velocity is also calculated by summing the story point estimates for each completed story. Story points are purely an estimate of the size of the work to be performed. The duration of the project is not estimated as much as it is delivered by taking the total number of story points and dividing it by the velocity of the team.

The most common way of estimating a User Story is by using Fibonacci series as it forces them to provide a relative estimate. It is easier for anyone to answer “Is that 5 or 8” rather than 6 or 7?

Retrospection- After the Sprint Review, the Development Team holds an internal meeting to review the Sprint and use it to improve the process (lessons learned) in the next Sprint.

Also, find out what's not working and use the time to find creative solutions and develop an action plan. Scrum Master facilitates this meeting. We generally use sticky notes in which each team member writes three things about sprint (which just got over.)

1. What shall we continue?
2. What needs to be stopped?
3. What needs to be started?

Then the Team looks for underlying causes and agrees on one improvement for the following sprint with acceptance tests built in, along with a commitment to review the results at the next Sprint Retrospective.

Over the course of time, some Scrum practices begin to slip, or the meeting has become perfunctory, not effective.  Let’s look at how you got here through the frame of the usual suspects for an ineffective Retrospective.

The Usual Suspects are:

The whole team thinks it’s a waste of time.

If this is the case then ask the team why it is a waste of time? More likely the meeting is not managed effectively and the outcome of the meeting doesn’t lead to change in the action plan. Set the agenda of the meeting before it starts, and work towards it collectively.

Retrospectives aren’t valuable since we don’t have any impediments.

According to me, this is the biggest impediment like fear of conflict or lack of trust on team members.

 The Retrospective is just too hard.

Some team impediments are big.  Too big to solve in one meeting.  It’s important to make meaningful progress and keep the momentum going each Sprint, and this is most easily done by breaking down issues into something that can be accomplished and has a clear definition of done.

We do it but it doesn’t have an impact.

Scrum is there to help the team to deliver the products at a faster rate with a steady increase in velocity but if the flat-lined means retrospections are not able to find the root cause of it.

If the above conversations are true then the corrective actions need to be taken.

Adopt a new practice to rejuvenate your Retrospectives.  Sometimes it’s as easy as changing the way the question is asked and the Happiness Metric is a great way to do that.  

The Happiness Metric is a simple tool used to focus your Retrospective and collect actionable information.  It works like this:

Ask each Team member:

1. On a scale of 1-5, how happy are you with your role in the company?
2. On the same scale, how happy are you with the company?
3. What specifically increased your happiness last Sprint?
4. What specifically decreased your happiness last Sprint?
5. What would increase your happiness for the next Sprint?

By focusing on your retrospective, you will increase velocity, finish early and accelerate faster. Try it, if it doesn’t work there will always be the next sprint.

Continuous improvement is what sustains and drives development within an agile team, and retrospectives are a key part of that.

In the Scrum Guide the role of Functional manager is not specifically defined. As scrum focuses more on the self-organization more of Functional Manager involvement is not required if they do so, then the team is not following the correct way of Scrum.

• Functional Managers usually retain the job of assigning individuals to projects. They will be expected to continue to make these decisions based on the competing needs and career aspirations of individuals, locations etc.
• In few organizations the role of a functional manager is accustomed to assigning roles to the individual which now after transition they will not be able to do that as an individual selection of work is a fundamental aspect of how the team self-organize and must be left with the team.
• They should now start working in the bottom-up approach. The manager should say “Here is our purpose and direction-I will guide and coach.”
• They also retain the responsibility for developing the people in their groups. Securing the budget and time, encouraging them for innovations, challenging them, build the leader in them are all parts of the functional manager role.
• They also retain the role of hiring and firing decisions which not even scrum master and product owner has this level of authority.
• Writing periodic reviews by taking the inputs from coworkers is also the prime responsibility of the functional manager and they will continue to retain them.
• They can also attend sprint reviews and even quarterly planning meetings.

As per Scrum guide it is recommended to have the scrum cycle or iteration for 2 weeks.But there is no rule, this can be purely adjusted to 2-4 weeks as per the team and project requirements.

How to decide on iteration? —Check How to decide about the size of the iteration?

The roles defined by Scrum are:

1. Scrum Master-Servant leader between team and Product owner. Removes impediments for the team and always help them practice good agile practices.
2. Product Owner-Full control of the product. Key communicator between team and customer. Solves all queries regarding requirements and decide the prioritized backlog.
3. Development team-Team which works on requirements and built the potentially shippable product.

In addition to the above roles there are Product Management and stakeholders and customers are also involved during sprint reviews and providing feedback.

Planning Poker:

• The below figure shows the poker cards available to estimate the user stories.
• Before starting Planning Poker, select one story which is a reference story (from the current backlog or that we have done earlier)
• In this technique team, Scrum Master, Product Owner will sit around the table (Figure shown below) for the planning poker session.
• Each team member will have a set of Planning Poker cards of values (0,.5,1,2,3,5,8,13,20,40 and 100) these represents story points in which team estimates.
• At the start of the session the product owner will read the user story aloud, describing all its features and requirements.
• Then the team will estimate with the number mentioned on cards and show it to everyone. If all have given the same value then that will become the final estimate.
• If the values are different then estimators giving highest and lowest values explain their opinions and why these chose this value, until final consensus is reached.
• A good technique for small number of items in a small team
• Till the final consensus is reached team will have complete clarity on the user story.
• If the estimator doesn’t have any idea or couldn’t estimate can show (?) also.
• If the user story is estimated as above 20 considered as Epic which needs further break down into smaller user stories.
• Story point estimated as 4 story points is of double the effort, time and complexity then the story with 2 story points.

A nice feature of story points is that each team defines them as they fit. One team decide them as an ideal day of work (i.e. a day without any interruptions whatsoever-no meetings, no email, no phone calls and so on.). Another team many define a story point as ideal week of work. Yet another team may define as a measure of complexity of the story. The most useful is estimating by complexity. For This we use one reference story and on the basis of that we estimate other user stories. Suppose if the user story is 5 points then and If any user story looks big or complex then reference story we estimate as 8 or more story points and if it looks less complex, we may estimate it as 3 or below story points.

A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide broad brush relative estimates of effort for completing requirements stated in User Stories 

Story points further used to calculate the velocity of the sprint which is very helpful to predict the release dates.

• Attendees: Development team, Scrum Master and Product Owner
• When: At the beginning of the sprint.
• Duration: Approx 4 hours for a 2-week iteration
• Purpose: Product owner comes with the prioritized backlog and then the Scrum Team plans the items they are going to deliver in the Sprint and the way they will deliver them, estimate them, break into tasks. The team can ask questions to the product owner about the user stories if they didn’t understand properly.

I feel there is always an opportunity to improve. A retrospective is an opportunity for the team to inspect and create a plan to be enacted from the next sprint.

Retrospection is held after sprint review and just before the new sprint starts.This is will be a 1-hour meeting for a 2 weeks sprint, will extend in case of 4 weeks sprint. Scrum Master is the facilitator of this meeting and he should make sure Product Owner and entire team should attend this meeting.

During the Retrospective team discusses about the 3 things:

1. What went well in the sprint?
2. What could be improved?
3. What we should stop doing?

Scrum Master can ask everyone in the team to write at least 1 answer to each question an after that they can be discussed with the team. This is the opportunity for each team member to speak up and raise their voice against any decisions or issues.

Once we brainstormed the initial ideas, team will vote for any high priority item to be focussed on during the sprint.

Situation: When there are a lot of issues (Maintenance project or Ticketing project) from the field and the current project is team is handling both the things (current project and field issues) which methodology best suits.?

So, in my opinion the answer will be Scrumban (Scrum+Kanban) approach. Because here requirements are changing so frequently which is hampering the current project and sprint.

Scrumban is specially designed for project that requires frequent maintenance, having unexpected user stories and programming errors. Using these approaches, the team’s workflow is guided in a way that allows minimum completion time for each user story or programming error.

As in this approach we will not take up new task until the high priority task has reached the deploy state.

Few tips for selecting the process are:

1. Integrate workflows with a task list for better transparency. -Kanban
2. Scrum for continuously devotion to projects
3. Visualization of workflow-Kanban
4. Intense human collaboration and feedback-Scrum.

During the daily Scrum meeting one question should be about impediments, if any team member has any impediments, they should bring it in front of team and team try to find out the solution. Most of the cases team will only figure out the solution but sometimes it is beyond the ability of the team then Scrum Master prime responsibility to listen, understand and remove the impediments.

Recurring impediments should be dealt in retrospectives where team brainstorm and try to find out the root cause of the problem and discuss about the solution.

Having no impediment is itself a big impediment.

Scrum defines only 3 roles-Scrum Master, Product owner and Development Team.

Scrum Master:

1. Removes the obstacles/impediments that impact 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.

Product Owner:

1. Ensuring that the Team understands items in the Product Backlog to the level needed to start the sprint or the development process.
2. Responsible for prioritizing the backlog.
3. Collaboration with stakeholders and customers.
4. Develop Release plan and release dates.
5. Provides vision to the team.

Development Team:

1. The team is self-organizing and cross functional. The team consists of Developers, testers, Devops, Architects, Tech leads, Analysts, Designers etc. Scrum team works closely with each other to build the product incrementally, maximizing feedback opportunities, build with good quality. Incremental deliveries of a product ensure working product is always ready at each increment.

Product Backlog:

• High level feature descriptions are gathers early but they are minimally described at that time and are progressively refined as the project progresses.
• It is a list of all desired functionality not yet in the product.
• It is maintained by the product owner and kept in priority order which is why it is also called as prioritized feature list.
• Unlike the traditional requirements a product backlog is highly dynamic, items are added, removed and reprioritized each sprint as it progresses and team learn more about product, the users and so on.
• Changes in business requirements, market conditions, or technology, cause changes in the Product Backlog, making it a live artifact.
• High ordered items are clearer than low ordered items.
• More precise estimates are made based on the greater clarity and increased detail.

Sprint Backlog:

• Sprint Backlog consists of selected items from the product backlog which has complete details and clarity of requirements and on top priority.
• Sprint Backlog is a forecast by the team that what all functionalities will be made available in the current sprint.
• The team modifies the sprint backlog as the sprint progresses which helps in tracking the sprint. Modifications includes tasking out the user stories.
• Whenever some task is completed it is moved to completed and when all the tasks related to one user story reached completion (Definition of Done) state then after sprint review this user story is moved to completion.
• Sprint Backlog depicts the real time picture which team decided to accomplish in a sprint and it is completely owned by the team.

Scrumban means combination of Scrum and Kanban methodology.

Scrumban is specially designed for project that requires frequent maintenance, having unexpected user stories and programming errors. Using these approaches, the team’s workflow is guided in a way that allows minimum completion time for each user story or programming error.

As in this approach we will not take up new task until the high priority task has reached the deploy state.

The below board depicts the above situation.

Let us compare Kanban and Scrum Approach.

In SCRUM, the team meets daily preferably in the morning time when a day starts and this meeting is called daily scrum. This is strictly time-boxed to 15 minutes. This keeps the discussion brisk and relevant. All team members are required to attend the meeting.

Scrum master is optional for the daily stand up.

This meeting should not be considered as a problem-solving meeting. Issues that are raised must be taken as offline right after scrum meetings with specific groups of people.

During the daily scrum each team member should answer the following 3 questions:

1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your way?

By focusing on what each person accomplished yesterday and will accomplish today, the team gains an excellent understanding of what work has been done and what work remains. The daily scrum meeting is not a status update meeting in which a manager is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other. By this meeting, the team gets an idea about where the sprint is heading towards...Behind the schedule or ahead.

Velocity is a measure of work done by the team in a sprint. It is calculated at the end of the sprint by calculating total story points finished in that sprint.

For example – 

• If the team finished 20 story points in a sprint then the velocity is 20.
• It is a key feedback mechanism for the team. It is also a key metric in Scrum.
• It is recommended that stories which are incomplete or unfinished the credit to the points should not be given.

Velocity should be tracked throughout the sprint on the Sprint Burn Down chart and should be visible to all the team members. In case of the burn down is not proper Scrum Master and Product Owner can discuss with the team after daily stand up.

With velocity, the product owner can figure out how many sprints this product will the team takes to deliver the desired functionality and is ready to be shipped. Depending on the length of the sprint he can fix the release date of the product.

For an example, if the velocity of the team is 20 story points and total points estimated in the product backlog is 100 then the team is estimated to finish it in 5 iterations (2-week iteration then 10 weeks), in this way it helps in release planning.

It also facilitates how many stories can be finished in one sprint. Most of the sprint velocity keeps on oscillating but average velocity of past 3 sprints is a good measure.

Below table clearly defines when to use Scrum.

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.

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.

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.

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.

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

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.

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

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

• 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

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.

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.

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.

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.

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.

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.

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

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

• 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?”

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.

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.

If you have done any certifications then do list them out. <<insert links for KnowledgeHut Trainings registration>>

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.

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.

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:

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.

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.

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.

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.·         

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.

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

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

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.

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.

 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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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 a 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.

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.

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 

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.

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.

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.

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.

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!

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.

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.

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.

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).

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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’.

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.