Scrum Master

1.   What is Scrum?

Scrum is a framework for developing and sustaining complex products. Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

The Scrum framework consists of Scrum teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum's success and usage.

2.   What is Sprint?

The heart of Scrum is Sprint, a time-box of one month or less during which a "Done" useable and potentially releasable product increment is created. Sprint is the basic unit of Scrum development and is restricted to a specific duration Product backlog. Each sprint may be considered a project with no more than a month or four-week duration. Each Sprint has a definition of what is to be built, a design ad a flexible plan, that will guide building it, the work, and the resultant product.

3.   What is Scrum's empirical process control theory?

Scrum is founded on empirical process control theory i.e. empiricism. Empiricism enforces that knowledge comes from experience and making decisions based on what is already known. Scrum employs an iterative and incremental approach to optimize predictability and control risk. The three pillars to uphold the implementation of empirical process control theory are - Transparency, Inspection, and Adaptation.

4.   What are the Scrum values?

Successful use of Scrum depends on its values of commitment, courage, focus, openness, and respect by the Scrum team to build trust for everyone. People personally commit to achieving the goals of the Scrum team. The Scrum team members have the courage to do the right thing and work on complex problems. Everyone focuses on the work of the Sprint and the goals of the Scrum team. The Scrum team members agree to be open to doing all the sprint work. Scrum team members respect each other to be capable, independent people.

5.   What are the Scrum events?

Scrum prescribes four formal events for inspection and adaption as described in the Scrum Guide. They are - 

• Sprint Planning - The Sprint Planning Meeting is held at the start of every sprint and comprises of the development team, product owner, and the scrum master.
• Daily Scrum - Each day during the sprint, the project team assembles and discusses what was achieved yesterday, what is due today, and the roadblocks faced. This meeting is strictly timed for 15 minutes.
• Sprint Review - A meeting that reviews what was achieved in the course of the sprint and what is left.
• Sprint Retrospective - Team members reflect on the past sprints to learn from the previous mistakes and continuously improve.

6.   What is the purpose of the Sprint Planning Meeting?

The Sprint Planning Meeting is held at the start of every sprint and comprises of the development team, product owner, and the scrum master. The aim of this meeting is to:

• Ascertain the capacity of the team for the current sprint.
• Prioritize the items from the product backlog that are to be completed in the current sprint.
• Select the items from the product backlog to be done in the current sprint based on the capacity of the team.
• Plan the work and assign responsibilities for the complete sprint duration. The complete duration of the Sprint Planning Meeting is eight hours.

7.   How do you define a sprint backlog?

A Sprint backlog is a collection of requirements that the development team must achieve in the next sprint. A sprint backlog is created based on the development team’s capacity and the priority of the requirements. Conversely, a product backlog is a prioritized list of high-level requirements of the product.

8.   What do you know about a sprint burndown chart?

A sprint burndown chart is a graphic visualization of the rate of progress of the current sprint. This chart is updated daily over the course of a sprint. The Sprint Burndown Chart makes the work of the Team visible. It is a graphic representation of the rate at which work is completed and how much work remains to be done. The chart slopes downward over Sprint duration and across Story Points completed. What makes the chart an effective reporting tool is that it shows Team progress towards the Sprint Goal, not in terms of time spent but in terms of how much work remains.

If the burndown line is not tracking downwards by mid-Sprint, the team needs to quickly implement the Emergency Procedure pattern. Check out the slide show below to see an array of Burndown warning signs. It is important for the Scrum Master to help the Team to act early rather than drifting toward Sprint failure.

9.   What do you know about a Release burndown chart?

Progress on a Scrum project can be tracked with the help of a release burndown chart. The release 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. The ScrumMaster should update the release burndown chart at the end of each sprint.

The horizontal axis of the sprint burndown chart shows the sprints; the vertical axis shows the amount of work remaining at the start of each sprint. Work remaining can be shown in whatever unit the team prefers - story points, ideal days, team days, and so on.

On the release burndown chart, the team started a project that was planned to be six sprints. They began with 360 story points of work. To finish within six sprints, they planned to average 60 points per sprint. The first sprint went well and they completed 90, leaving 270.

Things continued to progress well during the second sprint, but during the third sprint, the estimated work remaining actually burned up. This could have been because work was added to the project or because the team changed some estimates of the remaining work. After that, things again went well.

10.   Who all constitute a Scrum Team?

Scrum Team comprises of Product Owner, Scrum Master, and the Development Team

11.   Tell us the responsibilities of a Product Owner and Scrum Master?

The responsibilities of a Product Owner:

• Primary stakeholder of the project/product
• Create, edit, and prioritize user stories
• Add user stories to the product backlog
• Different from the scrum master role

The responsibilities of a Scrum Master:

• A facilitator to the project team
• Makes resources available to the project team
• Enforces the scrum rules on the team
• Manage and encourage the project team
• Chairs and arrange to stand up meetings

12.   What do you know about the term ‘Spike’ in relation to scrum?

A Spike is a time-bound activity to conduct analysis or answer questions rather than producing a shippable product. Spikes are usually planned to take place in between sprints.

13. What is the Velocity of a sprint?

The velocity of a sprint is the total amount of work the development team is capable of doing over the duration of the sprint. Velocity for a sprint is agreed upon based on the historical data available about the previous sprint of the project.

Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories.

Points from partially-completed or incomplete stories should not be counted in calculating velocity. Velocity should be tracked throughout the Sprint on the Sprint Burndown Chart and be made visible to all Team members.

Without Velocity, Release Planning is impossible. By knowing Velocity, a Product Owner can figure

out how many Sprints it will take the Team to achieve a desired level of functionality that can then

be shipped. Depending on the length of the Sprint, the Product owner can fix a date for the release.

14. What is a ‘Story Board’?

The progress of an agile project is represented by a storyboard. To do so, a whiteboard is divided into four columns ‘To do’, ‘In Progress’, 'Test’, and ‘Done’ and post notes are placed in each column indicating the progress of individual development items (user story/task). This way, everybody is aware of the current status of the project and of the user stories as well.

15. Are you aware of the term ‘Tracer Bullet’?

The tracer bullet is a spike with the current architecture, current technology set, and current set of best practices which results in the production of quality code.

16. What do we mean by the terms ‘Impediment’ and ‘ScrumBag’?

Impediment denotes the ‘cause’ that is hindering the team member to work to its fullest capability and ScrumBag refers to the person, group, or any other blockers that could be a factor for Impediment.

17. Have you heard of the term INVEST in relation to scrum?

INVEST is a mnemonic describing the characteristics of a good user story:

Independent – The user story shouldn’t have any dependency on any other user story.
Negotiable – They could be changed and re-framed.
Valuable – They are able to add value to the end product.
Estimable – It should be possible to estimate them for better planning.
Scalable – they should be small-sized and manageable.
Testable – the tester should be able to verify the end result of the user story.

18. What do you know about Planning Poker?

Planning Poker is an agile planning technique aimed at gaining consensus on the estimated time to complete an activity. Team members are given Planning Poker cards with values like 1,2,3,4 and these values represent the estimation unit (hours, days) Then, a user story is discussed and the team members are called to disclose the duration that an activity is expected to take by displaying a Planning Poker card. If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss their estimates, and the same process is repeated until the complete team reaches a consensus.

19. What do you know about Increment in Scrum?

The increment is the sum of all the product backlog items completed during a sprint and the value of the increments of all previous sprints. At the end of the sprint, the new increment must be in a usable condition and meet the scrum team's definition of done. It's up to the product owner whether he/she releases that particular increment into production or not.  

20. What do you know about Story Points?

Story Points is an estimation technique for expressing an estimate of the overall effort that will be required to fully implement a product backlog item. When you estimate with story points, you assign a point value to each item. The raw values which you assign to any item are not important. What matters here are the relative values. A story that is assigned a 2-story point should be twice as much as a story that is assigned a 1-story point. It should also be two-thirds of a story that is estimated as 3 story points.

21. How can a non-technical ScrumMaster be able to come to a consensus on estimations?

A non-technical ScrumMaster need not be able to come to a consensus on estimations. It is the Dev Team members who need to come to a consensus on estimations for any user story. If all Dev team members come up with either the same story points or nearly the same story points for any user story, then that story point is the estimation for that particular story. So, even if the ScrumMaster is non-technical, that wouldn't make a big difference.

22. What is the step-by-step process to facilitate a backlog refinement meeting in Scrum with Scrum team members?

Facilitating a backlog refinement meeting, also known as backlog grooming or backlog refinement, is an important activity in Scrum to ensure the Product Backlog is well-prepared and ready for future sprints. Here's a step-by-step process to facilitate a backlog refinement meeting with the Scrum team members:

1. Schedule the Meeting: As the Scrum Master or facilitator, choose a convenient time and duration for the backlog refinement meeting. Ideally, it should occur near the end of the current sprint to prepare for the upcoming sprint.
2. Prepare the Backlog: Review the current state of the Product Backlog before the meeting. Ensure that user stories and other backlog items are well-defined, appropriately prioritized, and estimated (if applicable).
3. Communicate the Meeting Purpose: Inform the Scrum team members about the purpose of the backlog refinement meeting. Explain that the objective is to clarify and refine backlog items to increase their readiness for future sprints.
4. Set Expectations: Clearly communicate the meeting's agenda, expected outcomes, and timebox. Encourage team members to come prepared by reviewing the backlog items in advance.
5. Start the Meeting: Begin the meeting by reminding everyone of the meeting's purpose and agenda. Ensure that all necessary team members, including the Product Owner, Scrum Master, and development team, are present.
6. Review Backlog Items: Start with the highest-priority backlog items. Read out the user story or backlog item and provide context if needed. Allow the team to discuss and ask questions for better understanding.
7. Collaboratively Refine Backlog Items: Encourage the team to share their insights, concerns, and suggestions for improving each backlog item. This may involve breaking down large items, adding acceptance criteria, or removing ambiguity.
8. Estimate Effort: If your team uses story points or other estimation techniques, involve the team in estimating the effort required for each backlog item. This can help with future sprint planning.
9. Update Backlog Documentation: As the team discusses and refines each item, ensure that the necessary changes and updates are made in the backlog documentation. This includes capturing new information, updating priorities, and adding or modifying acceptance criteria.
10. Prioritize Backlog Items: If any changes affect the prioritization of backlog items, collaborate with the Product Owner and the team to adjust the order based on business value and dependencies.
11. Summarize and Conclude: As the meeting comes to an end, summarize the outcomes, decisions, and action items. Ensure that everyone is clear about the refined backlog items and any next steps that need to be taken.
12. Follow up on Action Items: After the meeting, follow up on any action items or tasks assigned during the backlog refinement. It may involve updating documentation, seeking additional information, or clarifying any outstanding issues.

Remember, backlog refinement is an ongoing process, and not all backlog items may be refined in a single meeting. Regularly schedule and conduct these meetings to continuously improve the readiness and quality of the Product Backlog.

23. What is a DEEP product backlog?

DEEP is an acronym used to indicate a few key traits of a product backlog.

• Detailed Appropriately: stories in the backlog contain enough information to be understood and discussed by the cross-functional team.
• Emergent: it is easy to add new stories and items as new information arises. Nothing is set in stone.
• Estimated: the amount of effort required to complete each user story is relatively estimated with a standardized measure agreed upon by the team.
• Prioritized: items on the backlog are ranked based on their value and the strategic purpose(s) they serve.