Scrum is a factual process where decisions are made on the basis of observation, experience, and experimentation. It is an agile project management framework that helps teams manage tasks through a set of values, principles, and practices. Whether you are a beginner or an intermediate, or an expert Scrum professional, this guide will aid in increasing your confidence and knowledge of Scrum. The below Agile Scrum interview questions and answers will get you acquainted with different types of questions that you may come across during your Scrum interview, like Scrum roles, events, artifacts, etc. Also, this guide brings you step-wise explanations for every question that will aid you in understanding the concepts. With Scrum interview questions by your side, you can be positive about preparing well for the upcoming interview.
One of the most frequently posed Scrum interview questions, be ready for it.
Methodologies in the IT world mean detailed, stringent, defined principles and mandatory processes and predefined algorithms. Every process or step should be carefully followed in sequence and documented properly.
Scrum is always misunderstood as a methodology rather, it is a set of instructions given mainly for the product, which has high uncertainties, complexities, and unpredictable.
It is a process that works best for all the players that emerge from the use of Scrum within the set boundaries.
Scrum as a framework describes roles and rules upon principles that help and facilitate people in a low-prescriptive way.
The Scrum framework leaves different options and tactics to play the game as it replaces the defined algorithmic approach with respect to people and self-organization to deal with unpredictability and uncertainties issues. The Scrum core values give direction to the actions and the behavior of the Scrum team and the additions they make to the framework.
One of the agile methodologies is Scrum which implements Agile principles.
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.
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.
An example is given below.
A staple in Agile Scrum interview questions, be prepared to answer this one.
TDD is defined as programming practice that 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 the intention of passing 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 the application code is added/re-factored the tests are rerun. 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:
Benefits of TDD
BDD is an extension of TDD. The major difference between TDD and BDD are:
This difference brings in the need to have a language which can define, in an understandable format.
Features of BDD
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:
This question is a regular feature in Scrum interview questions and answers, be ready to tackle it.
The four values of Scrum as per the Scrum Guide are:
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.
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.
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.
With short sprint cycles, the customer change in requirements can be incorporated easily in the next iteration, whereas in 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:
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.
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.
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
| Agile Testing |
| Testing is not a separate phase and carried out as a part of iteration |
| Testers and developers work together |
| Testers are involved from the requirements phase so that they will be able to write the test plan and acceptance criteria. Also, Logical Acceptance test cases would be ready along with requirements |
| Acceptance testing is done in each iteration and customer feedback is taken |
| Every iteration completes its own testing thus allowing regression testing also in each iteration in case of release of new logic or functionality |
| Continuous testing with test levels overlap |
| The entire team is responsible for the testing activity |
| Client involvement is needed throughout the phase |
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.)
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:
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.
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:
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:
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.
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:
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:
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:
Product Owner:
Development Team:
Product Backlog:
Sprint Backlog:
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.
| Scrum | Kanban |
|---|---|
| More perspective | Less |
| Limit your (WIP) PER ITERATION | Limit your WIP (PER WORKFLOW) |
| Prescribe Roles like: Product owner, Scrum Master | No such prescribed roles. |
| Scrum resists change within an iteration | Free to add any task in “To do” |
| Scrum board is reset after each iteration | Not necessarily done as focus is on to finish one task completely and then remove. |
| Scrum prescribes cross functional teams | Team can set the ground rules as who can change/own the board, experiment and optimize |
| Scrum backlog items must fit into a sprint | No such rule but Kanban focus on minimizing lead time and level the flow. |
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:
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 –
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.
| When to use SCRUM | When to use Waterfall (Traditional Method) |
|---|---|
| Scope not clearly defined. | Scope is clearly defined upfront |
| Requirements changes frequently | Requirements are well defined |
| Project is complex and unpredictable | Project is simple and predictable |
| Incremental results have value and can be used by users (Production) | Product cannot be used unless it reached its milestone |
| Customer Available | Customer may or may not be there. |
There are three different ways of estimating velocity.
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.
How would you best describe the relationship between the Product Owner and the Development Team?
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.
Is the discussion of what to do next also an additional activity as a part of the Sprint Review?
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 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.
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:
XP focusses on software development techniques and as such contributes the following to the Agile community:
“As a {role name}
I need to {name of business process}
So that {business reason for the business process need}”
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.
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.
CI allows for any integration errors being found as soon as practicable and they are fixed before further development continues.
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.
The concepts embodied in the LSD Principles can be used to enhance Agile Values and Principles:
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.
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.
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:
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:
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:
The prime responsibilities of a Scrum Master are:
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.
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:
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.
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 not available, would you still conduct the daily stand up meeting?
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:
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.
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:
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:
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:
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.
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:
The major difference between Sprint and iteration are:
There are many lists of coaching techniques; the following is fairly a fairly comprehensive list but exhaustive:
This technique brings a clear structure into goals. Each goal or milestone comes with clear and verifiable elements instead of vague resolutions. The broad goal of “I want to grow my business” will be described in much more detailed and action-oriented steps by the client. The SMART goal could be: “I will win five new clients for my business this month by asking for referrals, creating two useful blog articles and social media networking”.
It’s easy to help them get going with just a few simple questions like: “What was the most valuable takeaway from this session?”. This coaching technique helps you to find out the client’s “A-ha” moments and to avoid misunderstandings.
If all these notes are organized in a shared stream that is accessible to both you and the client you can reread and recap these nuggets any time at later stages during the process.
Writing enhances your client’s power of observation and focuses during a change or development process.
A study with two groups has shown that people who write down goals and make a weekly progress report achieved their goals at a rate of 76%, whereas the participants of the group who didn’t write anything down achieved their goals at a rate of only 36%.
This ongoing feedback as a follow-up between sessions is a perfect way to monitor and evaluate the effectiveness of the coaching. It shows your clients that you really care about their progress and gives them the feeling they’re not alone with their challenges.
A coaching journal is similar to the ongoing feedback described before. Your clients can write down their emotions, experiences, observations, challenges, success, thoughts, and feelings. They don’t have to wait until the next sessions which might be in a week or two but can share what’s on their mind right at the moment where it happens.
A shared journal gives your clients the feeling that you’re always there for them and “listening” without the need for your presence. They can write whenever they feel like it; at night, in the morning, during the day, at the train station on the way to their workplace or while waiting for the doctor.
A coaching journal gives them the ability to focus on themselves only without any time pressure or distractions. Once written down they can always reread and recap prior entries at a later stage of their process. Once these thoughts are shared with you you’ll gain invaluable information that will take your coaching and mentoring to the next level.
Homework helps to see if and how the plans from each session are being applied; it helps clients to keep the focus on their plans, ideas, and goals.
Another benefit is that both of you know what is getting done and what isn’t at any moment during the process. You immediately see where they procrastinate or struggle and when your support is needed. The shared to-do list helps to set priorities, achieve milestones faster and keep track of the small wins during a coaching process.
It shouldn’t be just a vague description but a whole day from start to finish:
This technique will encourage the client to use his/her positive imagination and visualize what he/she truly desires.
Afterward, you can work together to get the actual steps to that “miracle” where the goal is achieved.
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:
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.
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.
Choose an iteration to maximize the value of feedback that can be received from inside and outside the organization.
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.
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
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.
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
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.
Refer to interview questions Article? Question 17.
When to use which framework?
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:
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.
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:
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.
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.
Timeboxing is the process of allotting a fixed and maximum unit of time for an activity. That allotted unit of time is a timebox. The goal of timeboxing is to define and limit the amount of time dedicated to an activity. The time-box set for the Sprints should not be longer than one month and should be selected considering different factors such as the risk and delivery time.
15 minutes. The purpose of the Daily Scrum meeting is to carry out communication between the team members. The Scrum meeting is timeboxed to 15 minutes irrespective of the team-size and is held at the same time and place each day to reduce complexity. Also, it is usually held in the morning time when maximum team members gather to plan work for the day.
Product Owner.The Sprint can be called off before ending up the Sprint time-box. Only the Product Owner has the authority to cancel a Sprint. This happens when the Product Owner realizes that it makes no sense to finish the Sprint, as defined in Sprint Backlog. The PO may cancel the sprint under the influence of any Stakeholder, the development team, or the Scrum Master.
There should be one Product Backlog and one Product Owner. Many Scrum teams, each with a Scrum Master can pull work items from a single product backlog and the presence of the product owners depend on the number of product backlogs. A certain project should have only one Product Backlog and one Product Backlog should only have one Product Owner otherwise, it would be difficult to deliver the product.
One. Multiple Scrum teams, each with a Scrum Master can drag their work items from a single product backlog and the presence of the product owners depend on the number of product backlogs. A certain project should have only one Product Backlog and one Product Backlog should only have one Product Owner otherwise, it would be difficult to deliver the product.
It is not an appropriate goal since Sprint Goal should be about expected business value.
The development team should ask the executive to work with the Product Owner. The product owner is the voice of the executives in the process of communicative discovery. How the feature is developed is up to the PO and the Scrum Team, and depends on the nature of the product under deployment and the availability of the stakeholders. The product owner represents the needs and desires of the executive to the development team and prioritizes their work that helps the team to do it in the right way.
No. The benefit of forming self-organizing teams is not that the team identifies some additional role within the scrum for its work that a manager has missed. Instead, it is that by enabling the team to self-organize, it is motivated to completely own the problem of performing the work at its best. In short, a self-organizing team is a group of motivated individuals who have the authority and ability to take decisions and adjusting to changing demands quickly and easily working together towards a goal.
The product owner only. A customer shouldn’t spend time detailing the product issues to the development team, this is the job of a product owner. The product owner is responsible for the project success and is finally responding to the customers, team and to the company. He/she is the voice of the customer to the development team and ensures that all channels of communication are open and that project has ample amount of support needed to succeed.
Yes, the length of the sprint can be changed but it should be fixed before starting the sprint. The product owner needs to ensure that the sprint is short enough to limit business risk and also short enough so that the team can synchronize their development work with other business events. Finalized Sprint length cannot be longer than 4 weeks (1 month).
The Development Team should it transparent that they cannot make a forecast with insufficient information, and negotiate with Product Owner on refining the stories to a Ready state. In scrum, each and every iteration starts with a sprint planning meeting. During this meeting, the PO and the team discuss which stories a team will handle that sprint. The Product Owner needs to help clarify the selected Product Backlog Items. Scrum Master can also coach the Product Owner on how to accomplish this viz. by having regular Backlog Refinement sessions. Later, the team can also discuss in Retrospective.
No. After developing a product increment at the end of each sprint, a Sprint Review meeting is held. The Sprint Review meeting provides a platform to the team members to show what they accomplished during the sprint. Scrum events are time-boxed to eliminate waste and reduce risks. The team needs to address the root causes and adhere to the time-box.
This indicates that the development team added new work. The line indicating effort remaining in the burndown graph varies from team to team and day to day. If more work items (user stories and issues) are added after the sprint started then this shows an upward spike. The spike indicates added work and the Product Owner cannot add new work to Sprint Backlog without the consent of the Team.
No. The Sprint Goal gives some flexibility to the Development Team. If the work turns out to be different than expected, the Development Team collaborates with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint. In that case, the development team discusses with the PO and reaches the conclusion.
The development of the Scrum framework is not linear; different people did independent studies and experiments and gradually the ideas and concepts coalesced into what we know today as Scrum.
Probably the first publication that compared product development to the game of rugby, moving the scrum down the field, was the white paper “The New New Product Development Game” by Hirotaka Takeuchi and Ikujiro Nonaka, published in the Harvard Business Review in January 1986.
In this whitepaper, the authors researched the product development methods of prominent and successful companies and concluded that, in the main, success relied upon:
They called such processes ‘Holistic Methods’ as opposed to the waterfall ‘sequential’ processes.
Some sources attribute the ‘invention’ of Scrum to Jeff Sutherland, John Scumniotales and Jeff McKenna in 1993 when they implemented Scrum at the Easel Corporation.
Independently, Ken Schwaber, as a software product development manager in the 1980s and early 1990s, recognised patterns of failure in many product development initiatives that used ‘waterfall’ approaches.
Ken tells the story that he approached a process engineering company, described the software development environment and ‘waterfall’ process; he was told that a ‘defined process’ such as ‘waterfall’ was very unlikely to succeed consistently in a software development environment; what is needed is an ‘empirical process’ that allows process change from feedback from short experiments.
You would need to ask Jeff or Ken how these 2 first came together to ‘compare notes’ but they collaborated to produce the first public presentation of Scrum at OOPSLA 1995.
There have been many other people involved with the development of the Scrum framework; people such as Jim Coplien and Mike Beedle.
Ken Schwaber and Mike Beedle published the first Scrum book, ‘Agile Software Development with Scrum’, in 2001.
The Inspect and Adapt process is important throughout the Sprint but especially during the ceremonies:
The results of these Inspections should lead the team in considering the Adaption of the process that they followed
The empirical process control theory asserts that knowledge comes from experience and making decisions based on what is known ie at defined points within an overall control process, teams must inspect what has happened and, from that experience, adapt the process to what will happen.
The Scrum framework is founded on empirical process control theory so the included ‘Transparency, Inspect and Adapt’ processes are indispensable.
Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. If the transparency of artifacts is incomplete, these decisions can be flawed, the value may diminish and risk may increase.
Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work.
If an inspector determines that one or more aspects of a process deviate outside acceptable limits and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.
Transparency and Inspection are important in the Daily Scrums and Sprint Reviews. Although Adaptation is mainly considered during the Sprint Retrospective, it should be considered at any time during the Sprint if the current process is significantly detrimental to the best value being achieved.
When problem-solving and idea creation is needed, for example when constructing the Product Backlog from a product Vision, Objectives and Expected Benefits, there are 2 strategies that are usually used, divergent and convergent thinking.
Divergent Thinking
The “divergent thinking” strategy used to solve problems is the proposal of multiple possible solutions then examining each to determine the solution that will work.
In a ‘problem solving’ workshop, the participants are asked for any ideas individually; writing on ‘sticky notes’ is a good idea. The results are analyzed to see if there is any overlap and the participants agree on a single list of potential solutions.
Brainstorming and free writing are two processes that involve divergent thinking.
During the analysis of the potential solutions unexpected combinations may be made, information may be changed into unanticipated forms, connections among remote associates may be identified. In divergent thinking, a single question returns multiple answers and though the answers vary considerably depending on the workshop participants, all answers are of equal value; each proposed solution may not have existed before and therefore may be novel, unusual or surprising.
Eight elements of divergent thinking:
Divergent thinking has been detected in people with personality characteristics such as curiosity, nonconformity, persistence, and readiness to take risks.
An extreme example of divergent thinking was when Twitter developed an online service that did not have any obvious practical application. The company deployed a basic application to find out how people used it and, based on the findings, refined the application. Though launching something and finding out what the market for it is only after the launch doesn’t have to be a bullet-proof strategy (in most cases it is not), this worked for Twitter.
Convergent Thinking
Once the divergent thing ‘phase’ of the problem-solving session has been ‘completed’, the workshop participants use convergent thinking to bring together the different ideas to determine a single best solution.
The term “convergent thinking” was ‘created by Joy Paul Guilford. He came up with the term as an opposite term to “divergent thinking”.
Convergent thinking needs speed, logic, and accuracy and relies on identifying the known, reapplying techniques and amassing stored information.
A vital part of convergent thinking is that it produces one best answer; you either have a right answer or a wrong one.
An example of where convergent thinking would be used is when the problem is:
“If there are 3 potential outsourcing companies, which one do we choose?”
This would require listing all the criteria that the ‘buying’ company need from an outsourcing company and examining each to see which has the best ‘off-the-shelf’ fit or maybe which is open to negotiate to meet all the required criteria.
Summary
Making decisions in a group has its advantages and disadvantages; the main advantage is that there will be more information and data available by which to make the decision; the main disadvantage is that it can take a significant amount of time.
Let us consider first a jury for a trial. The decision that they must make is ‘black and white’ or binary; is the defendant guilty or not guilty?
A jury session usually starts with a vote amongst the jurors, guilty or not guilty. There follows a discussion between people on either side why they have the opinion that they have. By this means, each juror hears opinions about pieces of evidence that they may have forgotten or dismissed and the relative importance of different pieces of evidence.
After a set time, another vote is taken to see in which direction the overall opinion is ‘going’.
It depends on whether a majority or unanimous verdict is required; if majority, once the requisite number of people all vote the same way, the decision is made; if unanimous, there is a danger that the longer the discussions go on, those in the minority will vote with the rest just to ‘get it over with’.
There is another decision that a jury can make, they cannot agree to the set majority or unanimous parameters and inform the judge.
But not all decisions are ‘black and white’, most represent a range of options that must be chosen from. The following are the major recognized ways in which groups of people can come to a decision:
Let us see all the voting processes in detail that may be used:
The problem with this voting method is that the winning option may only be supported by a minority of the participants; it is unlikely that those in the majority will actively support the decision.
This method is a structured communication technique for groups, originally developed for collaborative forecasting. It involves ‘experts’ answering a series of questionnaires and after each questionnaire is completed, a facilitator presents anonymized results and the reasons for those results. The idea is that each expert modifies their opinion based on the reasons and it is expected that the range of opinions becomes smaller and converges with the ‘best’ decision.
You can possibly see that Consensus decision making is a less structured version of Delphi; all workshop participants are experts in their own field, but their opinions are not anonymized.
Using this method, participants are asked to place ‘sticky dots’ or use maker pens to indicate for which option they vote for. The may be given one vote or a range, identified by colors, such as ‘I want this one’ (green), ‘I would be OK with this one’ (orange) and ‘I do not want this one’ (red).
There are different ways of using the results:
with many facilitation tools, facilitative listening is perhaps most useful when there is a chance that conflict may arise. Facilitative listening is sometimes known as ‘active listening’ and is ultimately about making sure that all group participants are properly listening to each other.
The following are techniques to help with facilitative listening:
It may be that the listener does not totally understand the statements being made by someone:
Both of these are examples of paraphrasing.
Part of your responsibility as a facilitator is to be aware of the listeners ‘body language’ and if you believe that one or more are not fully understanding what is being said, you could ask:
Workshops are set up for participants to express themselves but more than just space for expression is needed. If a participant speaks without a sense of being heard, they are likely to either ramp up their expression or else shut down neither of which is desirable for collaborative decision making. Mirroring requires that the speaker can feel that they have been listened to.
Mirroring may take a variety of forms:
Mirroring may happen in the moment of a session or in after/between sessions as part of a longer, iterative process.
The effectiveness of Mirroring may be enhanced by checking with those reflected to see if the Mirroring was accurate.
Not all the Mirroring needs to be done by one central facilitator. A facilitator can also invite others to participate in Mirroring, whether in the whole group or in pairs or small groups.
Mirroring summarizes the state of current knowledge. Once what is now known is acknowledged, that naturally opens space for new ideas and creativity to emerge, whether for one participant in a meeting or for a group as a whole.
Participants in a decision-making workshop need to be focused especially when listening. Therefore, they need a space where they will be comfortable and without distractions.
As a facilitator, ensure that the workshop space:
This technique to aid facilitative listening is called ‘Taking Stack’ and its purpose is to facilitate discussion and decision making in which all participants have equal say in a conversation. Otherwise, in a structure-less setting, an individual or a small group of people could easily dominate and shut out other participants.
For this method, one group participant needs to fill the role of the Stack Keeper whose responsibility is to structure and order the dialogue of the decision-making process.
“The Stack” is the order of participants who are speaking. If a participant raises their hand to say something, the Stack Keeper puts them on “Stack”; their name is put at the bottom of stack list. When the person at the top of Stack has finished speaking, the Stack Keeper crosses their names off and announces who the next two participants on the stack are.
Thus, the Stack Keeper is the person responsible for identifying who speaks and when. The Stack Keeper must constantly be paying attention and looking around the room to see who wants to speak.
There are other hand gestures to indicate a request for more immediate contribution when someone else is speaking:
If a participant has a “direct response” to something that another group member said, they should make the hand motion shown in the picture (index fingers out, thumbs up, moving hands up and down in opposite directions). A “direct response” is only a correction to something that was incorrectly stated by another participant, an answer to a question that another participant had, or that is so important that it must be said at this moment.
The Stack Keeper allows this participant to state their response before the conversation goes on.
Correct Usage: “You asked who volunteered to take over your shift? That was me.” OR “Actually, the store spent $100 dollars yesterday, not $1,000.”
Incorrect Usage: “I disagree with what you just said, because…”
Any participant may make the hand gesture in the picture to indicate that they want to ask a “clarifying question.”
The Stack Keeper allows them to ask their question before stack goes on.
Correct Usage: “Wait, what were our expenses last week?”
Incorrect Usage: “How can you say that when you disagreed with Jeremy’s point?”
If a participant feels that the group discussion is not following the correct procedure or a discussion has gotten off topic, they may make this hand gesture and say out loud “Point of Process.”
The Stack Keeper allows them to speak before the next person at the top of the stack. They must then say how they think the discussion has gotten off topic or is not following procedure.
The coaching stance is what the Agile Coaching Institute (ACI) refers to as “the heart” of their Agile Coach Competency Framework. The coaching stance is supposed to be the place you start from and return to.
The coaching stance elements highlighted are:
Self-organising teams is one of the keys to Agile success but experienced developers who are used to working in a ‘command and control’ environment may find it difficult to adopt this Agile practice; they are used to being told what to do and sometime how to do it.
Instead of asking the Project Manager (PM) what to next, a developer needs to look at the Team Board and choose what to do next; instead of asking the PM how to do something, he/she should consult their peers on the development team; if no one knows, that is an impediment and the Team should discuss how to resolve the issue. The Scrum Master, as the Risks and Issues Manager, can help the team decide how to resolve the problem but should not be expected to solve it for them.
The main coaching techniques that a Scrum Master can use to help the team become more self-organising are
Powerful Questions are open questions ie they cannot have a yes or no answer; they usually start with ‘who’, ‘why’, ‘what’, ‘when’, ‘how’ or ‘where’; they may also start with statements such as ‘Tell me about …’.
Reflecting a statement back to an individual can help prompt further exploration; for example, “You said you were worried about the quality of the product so far … tell me more”.
For more information about Powerful Questions, see Coaching with NLP.
To foster the intrinsic motivation, we need to examine the following aspects of individuals and the Team:
Giving individuals and teams more control of what to do, when and how to do it, motivates them more.
Also, if individual Team members identify with their team (their tribe) the team becomes more autonomous and self-directing.
As a Scrum Master you should discover what the Team members know now and ask them to have a go at something small but significant in Scrum and give them the space and time to experiment on their own to work out how to do it.
Most people want to do better; by helping individuals and Teams toward Mastery leads to greater Team self-organisation.
Whenever possible, involve the Team in the early stages of product development; let them hear the discussions about forming the Product Vision and Objectives; let them have an input to the Product Backlog ordering.
For more about Autonomy, Mastery and Purpose see Drive by David Pink and Intrinsic Motivation by Richard Ryan and Edward Deci
Pay Attention
Give the speaker your undivided attention and show that you are hearing the message; your non-verbal communication, body language, can help the speaker feel comfortable.
Use your own body language and gestures to show that you are engaged.
Your own assumptions, judgments, and beliefs can ‘distort’ what you hear. As a listener, your role is to understand what is being said; this may that you have to ask questions to clarify what is being said.
There are many challenges facing self-organising teams which can be grouped into the following categories:
Organisational inertia. In organisations that have been around for some time, the way that things are done have become habits; many supervisor and management personnel are reluctant to change from fear of their job changing significantly or disappearing altogether
Individual Team members’ inertia. Individual Team members may have fears about:
A Scrum Master must be aware of these potential challenges to self-organisation, look for signs of them and help both the organisation and Teams to overcome them.
Below are 3 typical challenges faced by teams and the possible help that a Scrum Master can give:
However, the time to address the underlying problem to do with estimating is during the Sprint Retrospective when the estimates for each Sprint Plan PBI should be compared to ‘actuals’ to see if there was any common reason for the estimates being inaccurate or if there were one or two ‘one-off’ estimating mistakes.
If there was a common or systemic reason for inadequate estimates, the Team must re-estimate the Product Backlog in the light of the new evidence; if the errors were due to ‘one-off’ inaccuracies, the Team should re-estimate similar User Stories in the Product Backlog.
Emphasise with the Team that nobody is expecting ‘perfection’ straight away; the importance is that they take time to learn from their experience and apply that learning going forward.
The programmers aim is for ‘clean’ and simple code but the temptation is to produce something that works now without considering future maintenance needs. The fact that the resulting code may not be ‘clean’ and simple is known as Technical Debt.
There are 3 suggested solutions that a Scrum Master can encourage the Team to adopt to address potential Technical Debt problems:
Do not let the Team wait until the end of the Sprint to do the code reviews, have them do it once the programmer believes that he/she has finished. In this way, there is the shortest time between ‘finished’ and any refactoring that may be needed.
With TDD, no line of production code is written before a test has been written to test it, the test is run and is expected to fail. Only enough production code is written to pass the test. See Test-Driven Development.
Practicing TDD does require an Integrated Development Environment that supports it and to be successful, all programmers must have the discipline to use it.
Initially, some programmers may be reluctant to use it because of the perceived extra work; however, when they see that the maintenance effort is reduced by more than the extra initial work, they come to accept the practice.
Team Member Leaves: Each Team member has a list of responsibilities and capabilities including their own specialisation, DoD checking and contributing to work outside of their specialisation.
The Scrum Master should keep a list of all these responsibilities and capabilities so that when a Team member leaves the Team for some reason, the remaining members can distribute the leavers responsibilities and capabilities amongst themselves.
If it is not possible for any of the remaining Team members to take on any required responsibility or a required capability is not available, the Scrum Master must raise this as an issue with the Product Owner and management; a Team member training may be the resolution to the issue or an additional Team member may be introduced to the Team. In the latter case, the Scrum Master should monitor how the ‘new’ Team are managing their self-organisation.
See also Self-organizing teams – Challenges and Strategies.
Even good self-organising teams can face challenges with Retrospectives in how they are run and addressing issues that they discover.
The following are some of the most commonly experienced challenges with their suggested solutions:
Solutions:
The Team must devise a plan to attempt to resolve ‘external’ problems probably involving the Scrum Master as the Risks and Issues Manager
Although there may be parts of their process that are working ‘OK’, the Team should devise experiments to innovatively change some parts and review the changes at the next Retrospective
Solution: The Retrospective facilitator should change the format of the Retrospectives by using ‘games’ to elicit required information from the group; see Fun Retrospectives and Agile Retrospectives Ideas: Games For Your Next Retrospective for more ideas than a Retrospective facilitator could possibly use
All Talk, No Action: During early transformation Retrospectives, the Team are likely to come up with many impediments; the list may seem daunting and the thought of discussing them all is de-motivating. Also, although the impediments may be discussed and understood by all, there is no plan to resolve any of them
Solution:
Timebox the discovery of impediments. The Team members will, hopefully, only come up with their most important impediments
Treat the Impediments or Blocks List like a Product Backlog Before discussing any impediment, get the Team to order them in terms of Team importance Discuss only the top 2 or 3 impediments and produce plans to try to resolve them Every 2 or 3 days during the next Sprint, get the Team to state how the plans are going
The first item for the next Retrospective should be to discuss the result of the plans; removing the impediment if it has been resolved or putting it back onto the Impediments List for consideration with the rest of the un-resolved and un-discussed impediments.
Generally:
The following table compares how attributes differ between working groups and teams:
| Working Groups | Teams |
|---|---|
| Individual accountability | Individual and mutual accountability |
| Come together to share information and perspectives | Frequently come together for discussion, decision making, problem solving, and planning |
| Focus on individual goals | Focus on team goals |
| Produce individual work products | Produce collective work products |
| Define individual roles, responsibilities, and tasks | Define individual roles, responsibilities, and tasks to help team do its work; often share and rotate them |
| Concern with one’s own outcome and challenges | Concern with outcomes of everyone and challenges the team faces |
| Purpose, goals, approach to work shaped by manager | Purpose, goals, approach to work shaped by team leader with team members |
This is a frequently asked question in Scrum interview questions.
There are many lists of the key attributes of effective Agile Teams produced; the following list distills and collates the common themes of most of them:
Effective Agile Teams set their own Working Agreement, Ground Rules, whereby the members know and buy-into the Team working practices which are usually elements to do with all the following attributes.
In a successful agile team, the team members work together on features; UI designers, developers and testers work together to ensure that they, as a team, have finished a story.
All Team members are aware of their own and colleagues’ strengths and weaknesses so he/she knows who to go to for improvement advice for themselves and who else he/she can help to improve.
As the successful agile team collaborates to finish features, they avoid the problem of having many features started but none getting finished at the end of the Sprint.
Obtaining feedback at regular, short intervals is a major contributor to the success of an Agile team; they use 1 to 3-week Sprints so they can produce potentially shippable increments of a product to obtain feedback form the wider stakeholder community. During the Sprints, if it is not possible to work with end-users directly, successful teams will seek feedback at every stage of the development of each Product Backlog Item (PBI).
As in all product development, conditions are not always favourable in an Agile environment:
However, the Team must get the work done; Agile team members must be adaptable to any kind of situation (be it the ideal or the worst situation).
Agile team members must be willing to work outside their specializations. This does not mean that they are expected to work in areas that they know nothing about; they can help other Team members under their supervision; the simplest form of this is for anybody to run test scripts if they are becoming a bottleneck.
Good intra-Team communication is one of the major characteristics of a successful Agile team; Team members:
Successful Agile teams members are fully ‘bought-in’ the Product Vision and Objectives and are fully committed to achieving the best value for the business within time and cost constraints.
They try to find ways to share their knowledge, learn various new things and enhance their own skills.
Also, all Team members must be able to see where Team members’ workloads stand at all times; if someone is overloaded, members must be willing to help the over-burdened person so as to smooth workflow across the team; this would normally happen during the daily Scrum.
It's no surprise that this one pops up often in situational interview questions for Scrum Master.
There are several ways to help a team improve its performance, but they can be categorized as follows:
Ensuring the team has common goals and purpose: The performance of a team that is ‘pulling in different directions’ will never be optimal; all team members must know the product development and objectives and fully buy-in to them; no ‘ifs’ or ‘buts.’
Ensuring the team understands and embraces Shared Accountability: We all understand self-accountability; you do something wrong, and you pay the price.
Team Accountability or Shared Accountability is taking responsibility for others ie, team members must be aware of the work that others are doing and be prepared to challenge their work for the good of the team.
Having a Working Agreement: A Team Working Agreement states the ‘rules’ that the team will follow to produce a valuable product; is something that the team members discuss and agree; nobody ‘issues’ a Team Working Agreement to the team.
The agreement can contain anything that the team would feel is useful to enhance collaboration i.e.:
A homogenous team is one where the members are all similar in background, gender, age and culture; we are not talking about similar skill-sets but general life experience.
Homogenous teams have been shown to suffer from the following drawbacks:
All multi-staged models for team formation recognise different stages that a group of people go through from the start, getting together, to becoming a high-performing team.
There are several published models from those that involve rigorous mathematical steps to analyse team needs and individual attributes, such as that proposed in Two Multi-Objective Stochastic
| Stage | Key Elements of the Development Stage |
|---|---|
| Forming |
|
| Storming |
|
| Norming |
|
| Performing |
|
| Outperforming |
|
| Adjourning |
|
Models for Project Team Formation Under Uncertainty in Time Requirements, to the more simple and well-known Tuckman Model.
Tuckman’s model, first published in 1965, initially only had the first 4 stages in the table; he added the 5th and 6th stages in 1975.
At first the group of people are reliant on a ‘leader’ and as the group emerges as a team, they become less reliant on a ‘leader’ and become self-organising
A common question in Agile Scrum interview questions, don't miss this one.
The ‘Definition of Done’ (DoD) is a checklist of all the activities that must be completed for a Product Backlog Item (PBI) before it can be considered ‘Done’ and is fit for review by the wider stakeholder community and potentially released to the live environment; the DoD is a key artifact for Product Development quality control.
The DoD is assembled and agreed upon by the Product Owner (PO) and the Development Team members.
Potential Problems with initial DoD
There is a possibility that the Team will develop a minimalist DoD and submit it to the PO for approval; some PO will give it a cursory glance and approve it.
In such situations, as a Scrum Master, you should remind the PO that he/she is solely responsible for the value to be accrued from the Product Development and that he/she needs to understand each DoD element in case any have been forgotten or any are unnecessary; the best way to achieve this is for you to facilitate a DoD workshop with the PO and Development Team members.
Another problem with minimalist DoD is that they assume that small but significant steps in the development process will be done because ‘they are obvious’; they may be obvious in the ‘cold light of day’ but not so obvious in the ‘heat of development’; as a Scrum Master, you should encourage the rest of the Scrum Team to include more detail in the DoD than seems necessary; items can always be taken out if they are felt to be redundant.
DoD Examples
The DoD for software development may include items such as:
The DoD for a PBI is usually peer-reviewed by another team member that has not had significant input to the PBI development.
Given that Scrum is not just for software development, a DoD for non-software product development, such as running an event, may look something like this for the PBI ‘As the Invitations Coordinator, I need to send invitations to the event so that we maximize attendance’:
Once all the DoD items have passed their checks, the Invitations Coordinator is authorized to send out the invitations.
The ‘Agile Technical Practices’ or ‘Agile Programming Practices’ all come from work carried out or developed from other ideas by eXtreme Programming practitioners; They are not part of Scrum or any other Agile framework but have been adopted by many, if not most, Agile programmers as a ‘toolkit’ of ‘best practice’ for producing minimal, ‘clean’ and maintainable code. The list of practices, with explanations, is as follows:
There will be many artefacts that are best displayed on a wall and it is best to keep them in one place.Also, the Team members can obtain ‘osmotic communication’ just by being in the same area as others having conversations.
Because nothing is considered ‘finished’ the first time through (it may meet the Definition of Done for the current Sprint but may have to be modified for other functionality in a later Sprint), other programmers need access to all the code in order to update it when necessary; if they do not have access, they may write redundant code.
Contrary to some beliefs, this practice does not double the cost of development because the resulting code will be virtually bug-free thus reducing rework time considerably
The practice does require the use of an Integrated Development Environment (IDE) that supports TDD or access to a TDD framework that supports the programming language being used.
Integration system builds should be done as often as practicable to catch errors early and make them easier to find and fix.
Some organisations do a full build of source code that has been checked-in to the source code repository every 2 hours; some organisations do a full build each time code is checked-in to the source code repository.
This practice does require the use of automated system build systems.
One of the most frequently posed Scrum interview questions, be ready for it.
Definition:
Firstly, we must define what the Product Vision is. Just as with any Vision, the Product Vision should be a short statement of what the product is for. Here are some characteristics of a good Product Vision:
Roman Pichler, the acknowledged father of Visions, says that Product Visions should be:
Additionally, make it:
Examples
Before investigating how to help the Product Owner create the Product Vision with the Development Team, let us look at a couple of examples:
Whilst this Vision ‘breaks’ the one-sentence guideline, it does fit Roman Pilcher’s advice.
Ikea:
“At IKEA our vision is to create a better everyday life for the many people”
This is a short and broad Vision for the company that will drive the products that the company produces ie will a proposed product help ‘create a better everyday life for many people’.
So how does the Product Owner, who is responsible for the Product Vision, go about creating the Product Vision?
Firstly, the creation of a Product Vision is best done collaboratively; as a Scrum Master, arrange a facilitated workshop with the Product Owner, relevant stakeholders and the Development Team to ‘brainstorm’ ideas; you may facilitate the workshop yourself (see Creating A Shared Vision That Works).
There are 2 widely used ‘models’ to use to help create a Product Vision:
The idea behind the Elevator Pitch is to put together a statement about something to ‘pitch’ to the CEO when riding in an elevator; we are not going to do this; it is the elements of an Elevator Pitch that we need to explore for the product so that we can come to a suitable form of words for the Product Vision. There are different lists of Elevator Pitch elements; for now, we will look at the following list from Roman Pichler:
By ‘brainstorming’ the above elements, the workshop participants get a better understanding of the product and can converge onto a suitable Product Vision.
Roman Pichler has a downloadable Product Vision Board that you can use to organise the ‘brainstorming’ ‘sticky notes’ and capture the decisions:
In a facilitated workshop, the participants imagine the product to be a ‘shrink-wrapped’ physical box containing the product; or it may be that the product is to be ‘shrink-wrapped’.
The elements of the box are:
There is a good description of how to run a Design the Box workshop at Design the Box.
Again, as with the Elevator Pitch, the workshop participants get a better understanding of the product and can converge onto a suitable Product Vision
It is not advisable to go straight from the Product Vision to collecting requirements for the Product Backlog.
The Product Owner (PO) is solely responsible for the value produced by a Product Development and to have some understanding of this value the Product Objectives, Benefits and an initial Business Case should be investigated to check that, in all probability, the product will produce value for the company; it is no good having a great product if no one will buy it and/or it will take 5 years to recoup the development costs.
To help the Product Owner and Development Team move from the Product Vision to the Product Backlog, as a Scrum Master, you can arrange a series of facilitated workshops to determine the Product Objectives, Business Case and Backlog.
Product Objectives
The Product Objectives are a list of things that enable the meeting of the Product Vision. It should not be a long list; between 5 and 10 is usual; Objectives are not requirements.
Some examples:
Although a Product Vision may state some development attributes that can be measured, most do not; it is the Objectives that should be measurable. Some people use S.M.A.R.T Objectives.
The Objectives list may also be ordered by business value and may define what is to be included in a Minimum Viable Product (MVP).
Benefits
From the Objectives list, we can now make an estimate of the expected benefits that we expect the product to give to the ‘customer’ (internal and/or external) and the company; each Objective may contribute to more than one category of Benefit; for example, an Objective of “Reduce report creation time by a minimum of 50%” may have the following Benefits:
Although we have used percentage values in the examples above, it is recommended that actual monetary values are used.
Now that we have the expected Benefits from developing the product, we must now estimate how much it might cost to develop.
At this point, the Development Team may not have been chosen:
To help the PO create an initial Business Case, as the Scrum Master, arrange a facilitated workshop to include the PO, relevant stakeholders and senior ‘technical’ personnel to investigate the probable costs of:
From these investigations, the workshop participants must decide as to which option will give, potentially, the best value.
The costs of the potential solution option must be compared with the expected benefits to make a cost-benefit decision as to whether the proposed product development is worthwhile.
See the APM website and other websites for more detailed information and ideas.
Once the Business Case has been approved, the PO can turn his/her attention to creating the Product Backlog.
As the Scrum Master, organise a facilitated workshop to include the PO, relevant stakeholders and the Delivery Team to discover the Product Backlog Items (PBI), usually User Stories, that will fulfil the Product Objectives.
These PBI will be estimated by the Development Team and the results fed back into the Business Case to ensure that the cost-benefit analysis still indicates a viable development.
The Sprint Retrospective is a key ceremony for ‘Inspect and Adapt’ to aid Continuous Improvement.
Many organisations have only the Development Team, facilitated by the Scrum Master, to reflect on their past process performance and make plans to improve it.
However, The Product Owner (PO) is also a member of the Scrum Team and there are advantages to having the PO included in the participants of the Retrospective:
If the Development Team have ‘a problem’ with the PO, it is tempting for them not to invite the PO to Retrospectives but this ‘problem’ is an issue and as a Scrum Master it is part of your responsibility to help resolve issues; the Retrospective is the best mechanism to discuss and resolve problems between the Development Team and the PO.
A staple in situational interview questions for Scrum, be prepared to answer this one.
The Product Owner (PO) is responsible for all of the Product Backlog Items (PBI):
The Development team is responsible for estimating the size and complexity of each PBI; this will be done initially just before development work begins.
During the development Sprint Planning, the Team must select the next highest value PBI to be attempted during the Sprint.
However, as time goes on, the PO and Development Team need to apply any lessons learned from development so far to ensure that the candidate PBI are sufficiently well described and sized (but see Scrum.org Myth 14); this ‘confirmation’ is done during Backlog Refinement during which the following questions are answered:
All of these criteria and others to suit a specific situation can be documented as a ‘Definition of Ready’ checklist.
There are a series of blogs that make interesting background reading: Product Backlog Refinement explained. See also Grooming the Product Backlog
Techniques
Also known as Specification by Example (SbE)
Although using BDD requires a toolset that might not be available, you can use the structured language to create PBI Acceptance Criteria:
An example:
For many years, business stakeholders have seen or been involved with building products using the so-called ‘waterfall’ model; business stakeholders are intensely involved at the beginning of the development to specify the detailed requirements and do not get involved again until just before deployment to do User Acceptance Testing (UAT).
People get used to a way of working even if they experience problems with it; it is human nature to ‘get on with it’ and/or develop personal ways of mitigating the problems that they experience.
Many business stakeholders are sceptical about ‘wholesale’ changes to the way that they are being asked to work especially as, superficially, their involvement with the product development is significantly increased.
Also, many senior business managers are risk averse and require predictability from the product development process.
The reasons why the waterfall development model evolved are beyond the scope of this question; to explain Agile to a business stakeholder, you need to know the major elements of the waterfall model that can cause ‘problems’ for the business:
Each business stakeholder will have had frustrations based on one or more of potential waterfall problems; before trying to explain the whole of Agile, it is recommended to start by discovering which areas of the waterfall development process is causing the frustrations and explaining the aspects of Agile that will help overcome them.
One model of product development to base your explanations around is ‘The Iron Triangle’
Waterfall sets out to define all the detailed requirements and plan how they will be implemented; the resulting ‘contract’ assumes that features, time and cost are all fixed.
However, as already said, it can take a long time to capture the detailed requirements and plan their implementation; however, things never go according to plan (requirement changes, staff changes) and so, when trying to implement a ‘fixed’ requirements list, the result will probably be time and cost overruns.
An Agile product development approach turns the ‘iron triangle’ upside-down:
You can see from Figure 4 that with an Agile product development process:
The requirements variability is based on ‘high-level’ requirements and needs some rules to give the business some confidence; the main rule is the Minimum Viable Product (MVP).
One of the major advantages of an Agile product development process over a waterfall one is that the product is delivered incrementally allowing some return on investment before the product is ‘completed’. Incremental delivery can also help with experimentation when the product details are unclear; parts of the potential final product can be deployed early to get ‘customer’ feedback that will help produce a better product.
One of the important factors when explaining Agile to a business stakeholder is to make sure that they understand the major differences in output that they can expect compared with waterfall and the differences expected of them:
Another approach to answering this question can be found at How to Explain Agile to Your Stakeholders.
There are many opinions as to what the ‘typical’ impediments that Scrum Teams face are; the following list is not exhaustive but covers the impediments that Scrum Teams may probably face:
Also, when Development Team Members, new to Scrum, are under ‘pressure’, it is natural for them to revert to old work practices because they know them and having to think about and use the new work practices takes more time and increases the pressure.
Solution:
During the early stages of an Agile Transformation, the role of a Scrum Master as the Risks and Issues Manager, is key.
During the daily Scrum, he/she must listen to what the Development Team members have been working on and what they plan to be working on; note any item that does not seem to be adding to achievement of the Sprint Goal and discuss with the relevant developer after the Scrum has finished. If the item is a ‘hang-over’ from the old ways of working, the Scrum Master must identify the person who asked for the item and engage them in a ‘Scrum Mentoring’ session to explain why their request is inappropriate.
Similarly, the Scrum Master should question any developer that does not seem to be following the Agile and Scrum practices; for example, the developer may be building the user interface for a User Story from his/her own knowledge, because it is quicker, without collaborating with a relevant business person to get the correct information.
In organisations that are used to using Matrix Management for resource allocation, it is usual for one person to be working on multiple product developments or other work. This causes the individual to become distracted from the necessary work for any one of their assignments which results in reduced quality of their work and more time overall to complete the work.
Solution:
Scrum requires that the Development Team is made up of all the skills necessary for the development and that the relevant resources are dedicated to the product development.
The Scrum Master must work with the matrix managers to assign resources to one product development at a time for the long-term and not assign people based on short-term expediency.
There may be occasions when a particular Development Team member is considered to be the only person who can solve a problem outside of their immediate product development responsibilities; as long as this is to be a short-term (1 to 3 days) commitment, it is allowable but their reduced development capacity must be reflected in the Team’s expected velocity. If this situation is a common occurrence, it is a significant impediment to the Team’s progress and the Scrum Master must escalate the impediment to the Product Owner.
The team member skills are different for each ‘phase’ of the waterfall development process, whereas with Scrum we require all necessary skills to be available at all times throughout the development:
Solution:
As in Distractions above, the Scrum Master must work with the organisation resource allocators to ensure that Scrum Development Teams are composed of members with all the necessary skills for the development all of the time.
We expect Scrum Development Teams to be self-organising, cross-functional and work in a collaborative manner; traditional HR systems are an impediment to this goal.
Solution:
The Scrum Master must work with the HR department to make them more Agile. There is a good article from the Agile Alliance, Practicing Agility in Human Resources, to help with this HR coaching.
The ‘mechanics’ of Scrum are relatively easy to implement but it is implementing the Agile values from the Agile Manifesto, the Agile Principles and the Scrum values from the Scrum Guide that make Scrum work; these values are principles are the hardest part of Scrum to implement because they require an organisational culture change. Many organisations implement the Scrum ‘mechanics’ and ignore the values and principles and then wonder why this ‘Agile thing’ is not working.
Solution:
It is not possible to change an organisations whole culture overnight!
It is recommended that the Scrum Master, during the early stages of an organisational transformation, focus their ‘culture changing’ efforts on the stakeholders directly involved with a single product development.
Some may be sceptical so the Scrum Master may have to spend a significant amount of mentoring time with them.
Even though the Scrum Master may explain the implications of Scrum to sceptical stakeholders (and developers in some cases), some people do not believe until they see the results. Be prepared to answer all the sceptical people’s questions but do not let them introduce non-Agile practices.
In ‘traditional’ organisations where there are many meetings, many required meeting attendees get bored and turn up late because they know that the early Agenda items probably have nothing to do with them.
Solution:
When more than two people are required to discuss a topic or make decisions, hold a facilitated workshop. Although some say that a facilitated workshop should have an Agenda, the word ‘Agenda’ still indicates to some that a facilitated workshop is just another name for a meeting. Instead, have clear workshop objectives which are tightly focused around a single topic so that all workshop invitees are motivated to attend on time.
For those people who still consistently turn up late, the Scrum Master must individually mentor the person as to why it is important for them to be on time:
Solution:
The Scrum Master, as the Risks and Issues manager, must work with the affected developer to resolve the problem and if the resolution is not successful, he/she must escalate the problem to the Product Owner (PO) who may have to use their seniority and company politics to resolve the problem themselves.
Remember that the PO is solely responsible for ensuring the best business value emanates from the product development; blocked work reduces business value.
Solution:
The process for dealing with Supplier Issues will probably be different between ‘internal’ and ‘external’ suppliers.
In both cases, if resolution is not possible and given that there is Programme Management in place, the Scrum Master should escalate the problem to the PO and facilitate the problem resolution with the Programme Management.
A longer-term solution to minimise Supplier Issues is for the organisation to have all ‘internal’ suppliers using Agile techniques and only use Agile Contracts for engaging ‘external’ suppliers; you can find more information about Agile Contracts at Agile Contracts or Agile Statement of Work - Must-Haves and Agile Contracts - The Foundation of Successful Partnering.
This question is a regular feature in Agile Scrum interview questions, be ready to tackle it.
It is often tempting to see the immediate symptoms of a problem and fix things so that these symptoms disappear, only to see different symptoms appear later for a related problem.
To successfully solve problems, we must get to the root cause of the problem, so-called Root Cause Analysis (RCA).
The following are popular techniques used to carry out RCA:
Brainstorming the RCA relies on several people producing their thoughts and feeding off other people’s thoughts in order to converge on the probable root cause of the problem.
It is a relatively unstructured technique for RCA and it can be difficult to see the root cause amongst a great deal of data.
The 5-Whys technique is possibly the simplest RCA technique; it is a little like an annoying 5-year old asking question after question to the answers you give them. Essentially, the RCA workshop facilitator keeps asking “why” until an apparent problem root cause is discovered.
Generally, a minimum of 5 ‘Why?’ questions are asked, although sometimes more or less may be needed. For example:
This example could be extended to discover why the vehicle had not been maintained properly; the root cause could be that the need for regular servicing was unknown; the questions go on until the group agrees that a fixable cause has been found.
Flowcharting can help discover problems about a process in a graphical manner; a group of people affected by the problem will chart the supposed ‘As-Is’ process to see where the problem has arisen:
A Fishbone or Ishikawa Diagram is most useful when the “5 Whys” technique is considered to be too basic. In a Fishbone Diagram, the various causes are grouped into categories, with arrows in the image indicating how the causes flow toward the problem; categories used in the diagram are not pre-defined but common categories include equipment, processes or methods, measurements, materials, environment, and people.
This type of RCA seeks to understand the possible causes by asking questions such as “what actually happened,” “when,” “where,” “why,” “how,” and “so what” until a possible cause is identified and the consequences and significance is investigated further for each category; for example:
An Affinity Diagram is a tool that gathers large amounts of language data (ideas, opinions, issues) and organizes them into groupings based on their natural relationships. The Affinity process is often used to group ideas generated by Brainstorming.
The senior management of some (if not many) large organisations, having accepted the ideas behind Agile and knowing that the one-team Scrum framework is inadequate for their organisation, try to go straight from a traditional organisation to a ‘Scaled Scrum’ organisation.
Those that have tried this have hit severe cultural problems and perceive that ‘Agile does not do what it says on the tin’.
Implementing the cultural changes required for single-Team Scrum is difficult enough; the problems with trying to implement the cultural changes required for ‘Scaled Scrum” are exponentially more difficult.
The following is advice about when not to scale Scrum:
When beginning the agile journey, it’s critical that you start small and master the basics. Introducing a large enterprise framework with multiple dependencies presents a steep change curve and typically requires extensive investment.
In the early stages, you will reap greater benefits if you focus on developing the core agile principles and Scrum Values
Work on developing a good backlog, meeting commitments, reaching a standard velocity, and achieving high-quality output.
Additionally, starting small creates excitement, focuses on quick wins and learning more nimbly.
You may have reached the stage where you have multiple Scrum teams, that are working well in a Scrum environment and have started introducing larger epics that could benefit from being split across multiple teams.
This may seem like a natural point in the journey where you may start to ask whether you are ready to scale.
Before taking that leap, it is strongly recommended to optimise your current Scrum teams and Agile processes; really concentrate on strengthening your base in order to maximize throughput and ROI—instead of trying to build the product-development processes that you will need for Scrum at scale.
If you are at this point in your Agile journey, take a look at implementing test-driven development, continuous integration and deployment (not included in the Scrum Guide) and meeting commitments on a regular cadence.
Scaling Scrum has become incredibly popular in many industries; SAFe is a buzzword in the agile community; companies that are truly ready for enterprise frameworks are getting major rewards from them but that by itself is not a sufficiently good reason to move to an enterprise framework.
The transition from team-level Scrum processes to an enterprise framework requires a significant investment in change management. The move should be well thought-out and cautiously approached. If you have specific problems that scaling can solve, lay them out with an advisor and see if the journey is worth the investment.
When you’re ready, know that enterprise frameworks are tried and true tools that have delivered tremendous benefits for many organizations but you have to be at the right point in your journey to take advantage of these tools.
Expect to come across this popular question in SAFe Scrum interview questions.
When a product is being developed by multiple Scrum teams, it is recommended that there be 1 Product Backlog (PB) that all the Teams draw from to produce their own Sprint Backlogs.
It is probable that 1 Team may be dependent on an output from another Team before they can develop a particular Product Backlog Item (PBI); for example:
“As a customer
I need to pay for my goods/services
So that the company will send them to me”
Clearly, Team B has a dependency on Team A such that Team B cannot start their part of the payment functionality until Team A has completed their part.
When Scaling Scrum, the aim of Release Planning is to minimize the inter-team dependencies; it is improbable that all inter-team dependencies can be eliminated.
The following are some of the ways that inter-team dependencies could be handled:
MMF is the group of features that make up the MVP.
The Release Plan may be developed using the following steps:
For the payment example above, you may end up with a Release Plan Board and proposed Team Sprint plans that look something like:
Possible Release and Sprints Plans
You can see that all Release MMF are planned to be finished by the end of Sprint 2 leaving Sprint 3 to cater for any overruns.
With the advent of Component-Based Development (CBD), some organized their development teams into Component Teams and Product Teams that ‘glued’ together the necessary components.
If this continued into an Agile environment, then each ‘product’ development team would be dependent on separate component teams, and the required coordination would be an onerous task.
In an Agile environment, it is recommended to have ‘Feature Teams’; 1 Team should be responsible for the end-to-end development of all of a Feature’s User Stories.
This does not preclude the reuse of components; part of the organisation’s Design Strategy would require that a separate (possibly non-Agile) Component Management Team (CMT) reviews the output of the Development Teams to see if there is any functionality that could be componentised; the CMT are responsible for componentising the functionality and maintaining a Component Library.
Before writing any code, the Development Team search the Component Library for any components that would be useful.
Component Teams
Feature Teams
Scrum of Scrum meetings are conducted at regular intervals, probably at least once per week, to track dependencies among scrum teams.
Dependency threads or tags may be used for the visualization of dependencies among features and/or teams.
As part of Agile programme management, “independent” dependency teams may be used to track inter-team dependencies, blockers, and external dependencies and ensure they are taken to closure.
When scaling Scrum, many of the Scrum Events/Ceremonies need to be run with all programme Teams and, sometimes, all product stakeholders present.
This obviously requires a larger than normal space but the format used is important as well to maximise the value of the ‘workshops’; for example, for a Sprint Review where several Teams are ‘show-casing’ what they have produced, it would be boring for the stakeholders just to sit through multiple presentations and demonstrations especially if there are features being reviewed that they have no immediate interest in.
Scaled Scrum Events/Ceremonies are best run if everyone is co-located or can travel to the Event. This is not always possible or economical for organisations that have programme Development Teams and stakeholders scattered around the world.
The overall Programme Scrum Event process is similar for both non-co-located and co-located Events:
For non-co-located Teams and stakeholders, use should be made of tele-conferencing and video-conferencing technology.
Scheduling of combined and ‘break-out’ sessions can be difficult if the Teams and stakeholders are in widely different time zones; what would normally be a half-day Event may have to become a full day or even a day and a half.
For a co-located programme and stakeholders, it is essential that the ‘main room’ is big enough to hold all participants and is equipped with white boards and flip charts. If the room is really large, then a big screen and PA system may be required
The ‘break-out’ sessions may be held in the same room; some or all may be held in readily accessible smaller rooms.
The detail of how the ‘big-room’ Events may be run and facilitated vary but the 2 most common are Open Space and World Cafe.
The following are how the ‘standard’ Overall Programme Scrum Event Process may be configured for specific Events:
For one-Team Scrum we would only plan a Sprint at the beginning of a Sprint wherever we are in the Release cycle but for a programme, the stakeholders will need to have some idea what will be in the Release and the Teams need to produce outline Sprint Plans so that dependencies between Teams may be discovered, minimized and planned for.
Before the joint planning session, the Programme Manager will have worked with the relevant stakeholders to set a Release Goal and select potential features for the Release ordered by business value.
At the start the start of the Event the Programme Manager may allocate potential Release features to Teams or the Teams can volunteer for them.
The Teams, aided by relevant stakeholders, will go into concurrent ‘break-out’ sessions to decompose the features into User Stories and estimate the total effort required for each feature; this activity should be timeboxed to reduce the risk of the Teams going into too much detail.
The Teams will come together to see each other’s list of User Stories, to identify dependencies and distribute User Stories so that the effort is spread evenly between Teams.
The Teams then go back into ‘break-outs’ and produce an outline Sprint plan for each Sprint in the Release.
Finally, everybody comes together to produce/update the Release Plan Board with the outline Team Sprint Plans to ensure that the highest value User Stories will be developed first and that inter-Team dependencies have been catered for.
Some Programme Teams hold their individual Sprint Planning in the same space but separately and then ‘compare notes’ toward the end of the session to ensure that dependencies have been identified and catered for.
Some co-located Programme Scrum Teams hold the daily Scrums at the same time and in the same space but separately, then each team summarises any highlights to the other Teams.
Other organisations hold their Team daily Scrums as ‘normal’ and the Scrum Masters have their own ‘daily Scrum of Scrums’ at a convenient time.
A programme Sprint Review involves all Teams and all relevant stakeholders so the large space is needed for a co-located programme.
The workshop starts with the Programme Manager summarising what has gone on in the Sprint then the stakeholders attend as many Team demonstrations and hands-on trying of functionality as ‘break-outs’, held either in the same space or readily accessible ‘break-out’ rooms.
There are usually white boards and/or flip-charts available for stakeholders to make notes about things that they would like to be discussed toward the end of the Review when everybody comes together again.
The final ‘all-together’ session also includes the Programme Manager asking the stakeholders if there are any features/User Stories that need to be added to the Product Backlog; if there is anything that needs to be deleted from the Product Backlog and if the current ordering is still viable.
For non-co-located Teams and Stakeholders, the individual ‘break-outs’ can be run as concurrent timeboxed ‘webinars’ at scheduled times throughout the Review session; each Team running several ‘webinars’ to allow as many stakeholders the chance to ‘login’.
Although each Programme Scrum Team may hold their own Sprint Retrospective, it is important that a Programme Sprint Retrospective is held.
A Programme Sprint Retrospective follows the Overall Programme Scrum Event Process described above; the opening session is used to identify the good and bad things about how the programme is running and choosing the most important issues that need to be addressed.
Each ‘break-out’ session focuses on one area of issues and any members for any Team attempt to find the root cause of the issue and devise resolution plans.
There may be an interim coming together to discuss progress so far and maybe add to or subtract from the list of issues to be discussed in a second ‘break-out’ session.
During the final coming together, the results of the ‘break-out’ sessions are discussed and plans are devised to resolve the most important issues.
It's no surprise that this one pops up often in situational interview questions for Scrum.
Scrum team productivity is difficult, if not impossible, to measure for a single team and definitely impossible when comparing the productivity of different teams.
The metric that Scrum teams usually use to help them plan Sprints is the Development team velocity; some ‘managers’ believe that team productivity is directly linked to team velocity; the higher the velocity, the higher the productivity.
Velocity is team, product, and time specific and should only be used to aid Sprint planning.
The value that a Development team is delivering per Sprint cannot be used as a measure of productivity either; by its very nature, a team will deliver higher value at the start of the product development because they will be working on higher value User Stories.
Increasing Scrum team productivity can only come from ensuring that the fundamental ‘rules’ and ‘values’ of Agile and Scrum are being followed.
The following are the main areas of organizational change that will help improve Scrum Team productivity:
“Respondents report that senior management sponsorship and support is far and away the most important factor in adopting Scrum.”
AND
“… though senior management support is considered critical in Scrum adoption, only 7% of respondents reported that as visible in their organizations.”
The need for senior management Agile awareness and involvement in product development is that Scrum Teams are not isolated ‘islands’ in the organization; they have to interact with other parts of the organization that may resist changes to their work practices for the Scrum Teams to be productive.
The motivation for these other organization parts to adapt must come from senior management.
As an example, an Agile Team was formed to implement a new process to get connecting passengers from one aircraft to another, especially if the inbound flight was delayed. The new process involved the development of a new IT system, and the team planned to release increments of the new software monthly.
However, when it came to the first release, the team discovered that there was an organizational process that required 2 months before ‘desktop ready’ software could be made ‘live’.
The problem was resolved eventually by allowing the team to have a ‘fast-track’ release process, but the resolution took a month of discussions with the management of 3 other divisions within the organization.
When an Agile/Scrum transition starts, it is important to discover all the stakeholders, at whatever level in the organization, that can influence the early team’s productivity and ensure that they understand the possible implications to them and their subordinates of the Agile transition.
Mark Levison suggests one way of coping with the necessary senior management ‘education’ in his blog, Taking Organizational Improvement with Scrum Seriously; he proposes a ‘Change Management’ Scrum Team to develop the organizational change product.
Keep Teams Together – The ‘traditional’ approach to product development is to create a project, and assign the right people when they are needed throughout the project; there is never one coherent team, ie ‘bring people to projects’.
The Team members in Agile have all the skills needed to complete a product development; the Team size is generally constant for the whole product development.
If we take Tuckman’s group dynamic model, all groups of people go through ‘forming’, ‘storming’ and ‘norming’ ‘phases’ before the group becomes ‘performing’; it can take a significant amount of time before the ‘performing’ stage is reached.
It, therefore, follows that once a Team has reached the ‘performing’ stage, we should keep the Team together after the product development is finished; the ability to work well together as a team is more important than any individual skill.
Keeping teams together can be characterized as ‘bring projects to teams.’ Allow the team to determine their Sprint capacity – Some Product Owners (PO) ‘cajole’ some Development Teams to take on more work in a Sprint than the Team members think is possible.
This has 2 possible effects on individual team members:
Most of this extra work can be categorized as ‘fire-fighting’; there are 2 approaches to resolving this ‘problem’:
The Scrum framework is defined in The Scrum Guide; maintained and published by Scrum.org.
To get an answer to this question you must first ask the question ’What is Agile?’.
The definition of Agile is owned by the Agile Alliance that was formed in February 2001, at Snowbird, Utah. The first Agile Alliance publication was the Manifesto for Agile Software Development closely followed by the 12 Principles Behind the Agile Manifesto.
So, to answer the question, the Agile Manifesto and Principles are listed below with the explanation of how the Scrum Framework implements them.
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more”© 2001, the Agile Manifesto authors.
These are the 4 Agile Values and any product development framework that purports to be ‘Agile’ must embody these Values in the specifics of the framework.
It is worth noting here that although the Agile Manifesto specifically talks about ‘software development’, the Agile Values and Principles can be used to develop non-software products.
Agile Manifesto explanation and how Scrum embodies the Agile Values
1. Individuals and Interactions: There must be advice about how the people involved interact and communicate:
Scrum defines the roles for product development and specifies the necessary individual and group interactions. Although Scrum does define a product development ‘process’, it is tool agnostic.
2. Working software: The product development team’s focus must be on producing working increments of the proposed product and not in documenting what has or needs to be done:
The Scrum framework proposes a minimalist list of required ‘documentation’.
3. Customer Collaboration: The best results for product development come when all those involved work together as one ‘team’ to solve problems whether they be business or technical people and whether they are internal or external to the product development organisation:
Scrum defines a Scrum Team that includes business and technical people.
4. Responding to change: The major drawback to ‘waterfall’ processes is that they recommend obtaining all detailed requirements before development starts and create the development plan; ‘contracts’ are set in place and organisations think that they have a high degree of functional, time and cost predictability. However, as we all know, the development team discover hitherto unforeseen problems and the business change their minds. To cope with this situation, ‘waterfall’ processes introduced ‘Change Procedures’ which became bureaucratic and time wasting.
Scrum uses a high-level ‘requirements list, the Product Backlog, ordered by business value the content and ordering of which is the responsibility of the Product Owner. Furthermore, the Scrum framework has frequent, short events that include consideration of recommended and requested changes to the Product Backlog.
Acceptance criteria are sets of statements with clear pass and fail result that specify both functional and nonfunctional requirements of the user story. It acts as a guiding force for the developer to know on what basis their delivery would be evaluated for completion and correctness. Acceptance criteria is a set of expectations end user has from a certain feature or a user story. It is the responsibility of Product owner to create the acceptance criteria after talking to the customer.
For example:
As a teacher, I want to generate the assessment report so that I can evaluate the student performance. Acceptance criteria could be:
A common question in Scrum interview questions, don't miss this one.
| Definition of Done | Acceptance Criteria |
|---|---|
| It applies to all the product backlog items. | It applies to specific product backlog item as it clarifies one item. |
| Development team owns definition of done and it is agreed and understood by the complete scrum team. | Product owner owns Acceptance criteria and the development team should understand them. |
| It does not change very frequently, not expected to change during the sprint. | Acceptance criteria are negotiable between product owner and development team. |
| Meeting the Definition of Done means meeting the acceptance criteria. | Just meeting acceptance criteria not necessarily means that the definition of done has also been met. |
| It serves the purpose of making the unambiguous understanding that any product backlog item can be declared complete. | It serves the purpose of clarifying the business requirements and conditions, which must be met to satisfy the users for a given requirement. |
A Product owner’s primary responsibility is to make sure that the incremental delivery provides continuous and sustainable value to the customer and a Scrum master’s primary job is to make sure that Scrum team adheres to Agile principle and Value on a daily basis.
There can be times when Scrum team or a Scrum Master want to provide ideas/suggestions with respect to product development.
In such cases, the discussions should be done in a professional and peaceful manner to evaluate if the suggestions are actually going to help everyone [including team, PO, Scrum master and Customer].
The discussion can be based on Earned value management concepts, Scrum Values or Agile principles to correct the direction project is taking or make required improvements.
So, the short answer is, suggestions and ideas should not bother anyone and they should be done in a peaceful, professional manner.
Product discovery means, identifying what are the points, features and functionalities that are going to be useful to the customer, generate revenue and be realistic in terms of delivery. This requires the plans to be continuously updated and modified keeping in line with the latest feedback from end users. So this iterative process is known as Product discovery.
Product discovery process can be explained in the following manner:
This way, product discovery remains an ongoing process during the project duration.
Yes; Scrum or any other Agile methodology are designed to address the product discover process. There is no doubt about this.
Product Owner should arrange for a regular meeting between stakeholders and the team. The Team can ask the questions related to the requirements and get them clarified. These could be related to UI format or any technical risks. Sometimes when the stakeholders and product owners have difficulty in deciding the priority of the user stories but during discussion session with a team which consists of different skill set will be able to decide based on technical debt or some other hardware issues, which stories can be of high priority and can be delivered in the next sprint.
User story mapping workshop is very important and should be arranged with the help of the Product Owner and Scrum Master.
Sprint reviews and demos, release demos, and user interviews are also good venues for improving collaboration between the Scrum team and stakeholders. Communication and transparency are the keys to achieve collaboration. Wireframes, personas also can be used for better collaboration
Business stakeholders and others as relevant must be invited to the Sprint Planning meeting to get the necessary clarity on business value. Business value should be identified as a part of the Product roadmap planning exercise that happens ideally even before the project is taken up for execution.
It is the responsibility of the Product owner to update the business value of the user stories in the required table or the fields. Then high value stories should be discussed and planned over releases and sprints.
The estimation from scrum team helps in spreading those high value items over a reasonable period of time and if needed, they can be broken down into smaller pieces and hence deliver sustainable value to the customer over a period of time.
During execution, the information radiators and daily scrum serve as an indicator on whether the team is progressing as per commitment and in the right direction.
Technically speaking, Scrum master is correct and this user story is not a candidate for the current sprint. So your first response should be to see if you can move this story to the next spring and work with the designer to not delay from next time onwards.
But suppose, the final designs will be easy to understand and will be in line with the scope of work agreed with the team then you can discuss with team and Scrum master to complete the remaining tasks with in the story in first 2 days by that time, designs will be ready and they can continue.
So finally, It boils down to being Agile, adapting with the given situation while making sure that Agile principles are not diluted and team is not pressured into doing something they did not sign up for.
Even, the final decision will lie with the Scrum team and not with the Product owner.
There are multiple estimation techniques such as Planning poker, Affinity, wideband Delphi, expert judgement, PERT Weighted average that help in arriving at the reasonable and correct estimates. Please use these techniques in a workshop and work with the Scrum master as well to make sure these activities are done in true essence.
Reasons could be:
The Product Owner and Scrum Master should analyze the issue and discuss with each team member individually or in Retrospective meetings. Make them understand the Scrum process and encourage them to again trust their process and their own estimates.
There are scenarios where a team doesn’t have any clarity on user stories, as a result of which they add more estimates to the user story during the sprint planning meeting. The Product Owner and the team should own the responsibility of getting the clarity of user stories. The team should ask as many questions as they can to start work on the user stories.
Sometimes the team is working on current sprint but there is unplanned work which might come as the same team is working on the same. Ideally, it should not be but have seen this practically.
User stories have some technical debt example technology not defined, database storage etc. during implementation which tools to be used. In these conditions team sometimes estimate higher. The solution could be these could be treated as part of Definition of Ready state or take them as a spike user story.
When a team moves from the waterfall model to the scrum process, they may estimate it higher as they are new to the process. Training on Agile estimation techniques will be helpful.
Sometimes the team may estimate higher thinking that to do one particular task there is a dependency on other team or some vendors. Example-Purchase of hardware or License to some tool which is used for development etc.
Few things you could mention based on your experience in addition to the things mentioned below.
The concept of Sashimi means delivering the software in thin slices instead of making it a full product. As scrum follows the software development in iterative and incremental sashimi is one way of doing it.
Using this technique, all the requirements such as analysis, designing, coding, testing and documentation that are used in the constitution of a product are checked.
How does that work:
Same is depicted in the diagram below.
The Interviewer wants to know about your experiences with Scrum master or with any other Scrum roles.
You can start with the most memorable experience of all. For example, if you want to talk about Scrum master experience then highlight your answer with the following points:
If you want to talk about your role as a team member then include following points in your answer:
If you are planning to talk about your role as a product owner, then your answer should include the following:
While handling the Scrum team, the challenges are varied depending on the scenario and situation. The most challenging aspect included:
Use any of these points to elaborate on your challenges during the interview.
According to the 2 Pizza theory, the team size and the meetings duration should be equal to the time required to finish 2 large pizzas. This ensures you do not overshoot the time limits and make it chaotic.
Don’t worry about the toppings and crust type. ☺
A newly formed Scrum team should first work on the high value items that fit within the time boxed sprint. So this requires estimation to be in place for those high value items. The sprint should be planned in such a way that team gets enough time to attend discussions, daily scrum call, engage in product discovery process and work on tasks also. So ideally, you should be estimating for 5 hours of tasks per day per person. And remaining time for other activities.
Time invested in product discovery during this time will help smoothen the future sprints and hence provide sustainable development.
The intention behind this question is to check the candidate's viewpoint about how he will introduce and spread Scrum across the organization.
Like all living beings, any organization will show inertia initially to change and will be resistive. To overcome this behavior and win the executive support for your endeavor, start with showing the proposed benefits that will come by moving to Agile way of doing things.
It is important for them and you to understand that this change will not come by doing Agile projects alone; it needs to be supported by apt changes in the organization structure, process improvements, cultural change and most importantly, executive sign in.
Start by organizing series of workshops for them where they will get to work as a scrum team on dummy projects:
Use case studies to walk them through various companies in the world made the successful transition and the benefits they got out of that.
It is an on-going process to get their buy in first, followed by training, education, enlightenment and finally the implementation.
The first transition is to constitute the team based on the project needs and skills needed. This needs to be supported with thorough interview process where the technical, behavioral and attitude should be analyzed if they will be the right fit for the team.
This should be followed with workshops and training and dummy projects to drive the Agile principles and Scrum values into the individuals.
In parallel, there should be team building activities that create the bonding and take the team through Forming – Storming – Norming – Performing stages; so that when the sprint actually starts, the team is already in performing stage and hence, saving precious time of team development.
Managing risks in the project is the most important activity because risks can make or break your project. In risk management, you first need to:
This will help you create a list of risks, their probability, impact on your project and what are the actions needed to remove or reduce the risk. This is known as one of the following strategy:
Now once your risk response strategy is finalized then you need to perform the expected monetary value analysis where you will multiply the risk score [impact * probability] and the project budget to get the EMV. That is the amount of money you stand to lose if this risk gets realized and share this data with your senior management for actionizing.
Using these data points and strategies, you should continuously monitor your risks and get to the success point. ☺
One of the most frequently posed Scrum interview questions, be ready for it.
Scaling Scrum involves using multiple Scrum Teams to produce increments of a ‘large’ product; this will involve more people with the potential communication problems.
Of the Agile Technical practices listed in the answer to the previous question, the following are essential technical practices when scaling Scrum:
The practice of TDD is the only way to ensure that a full suite of tests can be run to test the whole codebase.
Scrum is a framework that helps teams to work together and address complex, adaptive problems while delivering products of the highest possible value. The Scrum Guide, which explains Scrum in a clear and distinct manner, talks about the Scrum artifacts, roles, events, and the rules that bind them together. To get a better understanding of Scrum and its benefits, one has to implement the Scrum framework. If you are looking to make that jump to a scrum master role, we recommend taking agile courses that suit your busy work schedule. Adapting Scrum adds numerous benefits to the organization like it improves the quality of a project, higher return-on-investment (ROI), higher customer satisfaction, increases the team’s morale, etc.
For Scrum, the most preferred and sought-after career path is that of a Scrum Master. The average Professional Scrum Master Salary is $116,184 per year.
Some of the top companies which use Scrum and Agile are Google, Apple, Philips, Valve, and many more. Hence it is very important to have a clear understanding of the concepts of Scrum and be ready with all the possible questions and answers that one might face during their interview.
To boost your confidence, these commonly asked interview questions for Scrum methodology have been answered by our experts, along with a few tips for Scrum interviews.
We have compiled a set of Scrum interview questions that will surely help you to revise your concepts and get a thorough knowledge of related concepts like Sprint, Sprint Backlog, Scrum Master, etc. These additional scrum master interview questions will prove to be handy as well.
Start your preparation in advance for your Scrum Interview with the help of the listed Scrum interview questions. Take the first step and prepare in advance for your Scrum Interview. Get yourself enrolled in knowledgehut agile courses and walk into your next interview full of confidence.
So gear up and start your preparation today! All the best!
Get a 1:1 Mentorship call with our Career Advisor
Book free session
Clear all
Clear all
The empirical process control theory asserts that knowledge comes from experience and making decisions based on what is known ie at defined points within an overall control process, teams must inspect what has happened and, from that experience, adapt the process to what will happen.
