SCRUM Ceremonies : 4 Formal + 1 Informal, in the Container called SPRINT

What is Sprint?

- It's an iteration, time-boxed, regular & repeatable work cycle... within all project work takes place.

Why Sprint is known as a Container?

- Because it contains/hosts other Scrum Events/Ceremonies like Daily Stand-up, Sprint Planning, Backlog Refinement(Informal), Sprint Review and Sprint Retrospective.

SCRUM Ceremonies

Why Backlog Refinement is called INFORMAL Ceremony?

- Because it doesn't take place at specific time. It's a continuous process and can happen at anytime throughout the Sprint. The Scrum guidelines suggests that Development Team should not spend more than 10% of their time for Backlog Refinement.

Sprint Planning

• It's beginning Ceremony for every Sprint. It is time-boxed, 8 hours for 4 weeks Sprint, less for shorter length Sprint.
• Inputs are: Product Backlog Items(PBIs) and Team's Velocity.
• Outputs are: Sprint Backlog and Sprint Goal. 
• Product Owner, Scrum Master and Development Team are Mandatory Participants.
• Other Subject Matter Experts(SMEs), Business Analysts and Stakeholders may be invited to help the Team as needed for better understanding of subject and customer requirements.
• It has 2 parts. In the 1st part ("WHAT" part), Development Team selects User Stories and Sprint Goal is decided.
• In the 2nd part("HOW" part), Development Team breaks down User Stories into tasks and comes up with the plan on how to delivery Production Ready Increment by end of the Sprint.

Daily Scrum OR Daily Stand-up

• As name suggests, it takes place daily throughout the Sprint. It's 15 minutes time-boxed.
• At same place, same time to avoid confusions and preferably at staring of the workday.
• Development Team members are Mandatory Participants. If Scrum Owner and Product Owner are working on Sprint Backlog items then they can also Participate.
• Scrum Master makes sure that Daily Stand-up takes place, all Development Team member participates and it's not running longer than 15 minutes time-box.
• Every participant answer 3 questions.

1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
2. What will I do today to help the Development Team meet the Sprint Goal?
3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

• This is daily KEY Inspect and Adapt event for the Development Team toward the Sprint Goal. They Inspect their progress, make changes as required and Adapt new game-plan the day. 
• The Development Team also updates Sprint Backlog items on Sprint Board. Based on these updates Sprint Burn-down chart is updated.

Backlog Refinement (INFORMAL Ceremony)

• It was previously knows as Backlog Grooming. They changed the wording from "Grooming" to "Refinement" to avoid confusion and alternate meaning.
• The MAIN Goal of this Ceremony is to bring User Stories into READY state as per the "Definition of Ready". This will help and save time of the Team during Sprint Planning.
• Inputs are : Incomplete User Stories and Product Backlog Items(PBIs).
• Outputs are : Ready User Stories and Product Backlog Items(PBIs).
• Product Owner and the Development Team are the Mandatory participants for the scheduled meeting.
• Any Scrum Team member can do the Refinement of Product Backlog at anytime subject to the approval from Product Owner.
• As per the Scrum guidelines, not more than 10% time of Development Team should go towards Backlog Refinement.
• As per the project complexity, Backlog Refinement Meeting can be scheduled more than 1 time.
• Ideally, it should be scheduled before couple of days of Sprint Planning. So, that Product Owner can order and prioritize the Product Backlog Items(PBIs).

Sprint Review

• It is also known as Demonstration Meeting.
• Customer, Product Owner, Scrum Master, Development team are Mandatory participants.
• Related Stakeholder and other interested parties are also invited.
• It's 4 hours time-boxed event for 1 month Sprint. Less time for shorter Sprint.
• Inputs are : Completed User Stories, PAST Increment and findings during the Sprint.
• Outputs are : Accepted User Stories, NEW Increment and updates to the Product Backlog.
• It's KEY Inspect & Adapt Ceremony for whole project for the Sprint.
• At beginning, Product Owner shares details about Spring Goal and what were the expectations.
• Then Development Team demonstrates working Product and invites attendees to Inspect and answers their queries.
• The Development Team also shares their new findings and any difficulties they faced during the Sprint.
• The Scrum team asks for the feedback from Stakeholders. All participant openly discusses their thoughts and next steps in the plan.
• Product Owner accepts completed User Stories based on "Acceptance Criteria" and "Definition of Done".
• Product Owner updates Product Backlog Items(PBIs) based on feedback received from Customer and Stakeholders.
• Based on all available inputs, Product Owner projects modified release plan and next steps.  

Sprint Retrospective

• It's a last Ceremony before end of the ongoing Sprint.
• Scrum Master, Product Owner and the Development Team are Mandatory participants.
• Product Owner skips this Ceremony, if he is busy or Development Team members are not opening up in presence of Product Owner. This is NOT recommended by Scrum guidelines.
• It's 3 hour time-boxed for 1 month Sprint. Less for shorter Sprint.
• It's a KEY Inspect, Adapt and Improve meeting for the Scrum Team.
• Scrum Master facilitates and teaches but participates as peer Scrum Team member.
• Inputs are : Feedback and Updates receives from Sprint Review, Observations from the Sprint.
• Outputs are : Updates for "Definition of Done"and Improvements for the Scrum Team.
• Discussion is based on following 3 points...

1. Inspect how the last Sprint went with regards to people, relationships, process, and tools.
2. Identify and order the major items that went well and potential improvements.
3. Create a plan for implementing improvements to the way the Scrum Team does its work.

• Identified Improvements are documented and assigned to the Team Member for the follow-up and accountability.

The Agile Manifesto : 4 Core Values and 12 Principles

Agile Manifesto consists of 4 CORE Values.

1. Individuals and Interactions OVER Processes and Tools
   
2. Working Software OVER Comprehensive Documentation
   
3. Customer Collaboration OVER Contract Negotiation
   
4. Responding to Change OVER Following a Plan
   

These values are derived from 12 Principles of Agile Manifesto.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
   
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
   
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
   
4. Business people and developers must work together daily throughout the project.
   
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
   
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
   
7. Working software is the primary measure of progress. Agile processes promote sustainable development.
   
8. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
   
9. Continuous attention to technical excellence and good design enhances agility.
   
10. Simplicity--the art of maximizing the amount of work not done--is essential.
    
11. The best architectures, requirements, and designs emerge from self-organizing teams.
    
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

5 Scrum Values : Commitment, Focus, Openness, Respect and Courage (CFORC,C4C)

Commitment

• Commitment => Dedication => Hard work => Passionate => Happy and Successful.
• Scrum team is made up of self-organizing Development Team members, Scrum Master and Product Owner. All collaborates but no one  controls. In this scenario, self COMMITMENT plays crucial role.
• Commitment is the key element of success for high performing teams.
• Committed teams emit positive energy which reflects on their attitude and productivity.

Focus

• Being Focused means you are working towards the GOAL. Constantly generate value to keep Customer happy and satisfied.
• Your mind (Conscious as well as Subconscious) is thinking about HOW to achieve the GOAL.
• It brings out Creativity. Many of "out-of-box" and disruptive idea comes from being Focused.
• Delivering working product each iteration is not easy. Fully Focused Scrum Teams can plan well ahead. They will be able to Inspect and Adapt to the changing situations effortlessly. They will be more AGILE.

Openness

• Openness, Fully Transparent, NO Secretes, NO office politics, NO back stabbing.
• Be Open about your capabilities, constructive 360 degree feedback, keep an Open mind about new ideas, new way of thinking.
• Actual status of the development is visible to all stakeholders. Team members willingly collaborates to generate maximum value.
• Impediments are also made visible, so fast actions can be taken.
• Bottom-up and cross-functional information flow will improve organizational productivity.
• It brings out TRUST between each other and strengthen bonds to work as single unit.

Respect

• Respect can't be WON, it MUST be EARNED. It's a core principle at Servant Leadership management style of Scrum Framework.
• Scrum teams are formed with cross-functional members having multiple competences.
• They all SHOULD Respect each others expertise and point-of-view to work as a cohesive unit.
• Management and Stakeholders SHOULD Respect Product Owner (PO) for his decisions for maximizing Product profitability and Development Teams productivity.
• Scrum Master SHOULD be trusted and respected for implementing Scrum rules and guidelines at every level of the organization for maximum benefits.
• Development teams SHOULD  be respected for their ability to produce working Product at end of each iteration.

Courage

• “Success is not final, failure is not fatal: it is the courage to continue that counts.” - Winston S. Churchill
• Give your best, Inspect the results, Adapt to improve....and do it again!
• Have the Courage to share your knowledge, to ask for help without hesitance, to try new ideas without fear of being criticized and to oppose when you don't agree.
• Constructive criticism is healthy for the progress. It brings out best and brightest ideas.
• Have the Courage to say NO to Product Owner, when s/he tries to give more User Stories for the Sprint.
• Have the Courage to say NO to people, who asks you to do additional work out of Sprint.
• Have the Courage to delay the Release, if Quality of the Product is not meeting the Acceptance Criteria or Definition of Done.
• Have the Courage to respect Time-box boundaries, which will improve team morale.

Definition of Done Vs. Acceptance Criteria

Definition of Done

=> Applies to Product Backlog Items (PBIs)

=> Creates Transparency and Robustness

=> Improves Quality of Development

Acceptance Criteria

=> Specific to Individual User Story
=> PASS or FAIL criteria provided by Product Owner/Customer

 Definition of Done (DoD)

• Set of ground rules, which applies to Product Backlog Items (PBIs)
• They should be developed by centralized Scrum body at organization level to be implemented for Scrum projects. 
• If no such rules are present at organization level then Development Team should create for the project and collaborate with Product Owner. Scrum Master should facilitate and provide guidance.
• DoDs are mutually agreed by Scrum Team.
• DoD creates transparency within Scrum Team about actual progress of the development. Anyone can evaluate HOW much work has been completed and WHAT needs to be done to complete the User Story.
• DoD provides guidance to the Development Team about the list of tasks must be performed to complete the User Story.
• During Review meeting Product Owner checks completeness of a User Story by comparing with DoD before announcing it as Done.
• DoD are used to improve Quality and robustness of the development.
• It helps Development Team to improve Velocity and improves overall productivity.
• During team Retrospective meeting, DoD can be reevaluated and modified as per the needs to improve development quality. Inspect and Adapt!

Acceptance Criteria

• Acceptance Criteria are the rules / limitations / wish lists given by the customer to Product Owner for that specific User Story. Those are the NEED of the market for that product / functionality.
• They are an important part of a User Story writing.
• They are specific to each individual User Story.
• Product Owner MUST write/provide Acceptance Criteria for a User Story before it gets selected into Sprint by Development Team.
• It provides clear distinction between IN Scope and Out of Scope parameters for a User Story.
• Acceptance Criteria are generally used to develop Test Cases, Use Acceptance Cases.
• If Development Team's code fails to pass the Acceptance Criteria, then Product Owner / Customer won't consider User Story as complete.                            

Estimate a User Story

You can't build a great building on a weak foundation. You must have a solid foundation if you're going to have a strong superstructure. - Gordon B. Hinckley

Estimating User Stories is an important FOUNDATION activity in Scrum projects. With experience and practice teams will get better at estimation, which will help to plan and forecast production Release Schedules and project completion dates.

Let's discuss few popular methods out of many available.

1. Planning Poker (Most Popular Method using Fibonacci series)

• Estimating effort required for a user story relative to each other.
• The TRUE democratic process, time boxed. Scrum Master may get involved to break the impasse.
• A Scrum team member will read user story out loud, which will initiate the discussion for clarification and better understanding.
• At end of discussion, each development team members will pick and raise a numbered card depending upon effort involved as per his/her understanding and analysis.
• Member with the highest and the lowest number will give their reasons for the estimation.
• Team members will discuss further and ask questions until all are in the agreement.

2. Estimating by 'Ideal Time'

• Estimating the size of User Story with work hours required to complete. Assuming those work hours are focused and without interruptions.
• These usually works for the projects where teams are seasoned and established. They have a fairly good idea about the work needs to be done and how long it usually takes. Repetitive activities with few variances.
• Team's Velocity per Sprint has been established. So, project forecasts and Release Planning are more accurate.

3. Using T-shirt size terminology

• Sizing User Stories with day-to-day T-shirt size terminology like S, M, L, XL etc.
• This method is used when teams are new to the concept of the Scrum and are involved in less technical projects. So, members can easily relate and adapt easily.
• It still serves the purpose of Agile methodologies and Scrum Framework which is to provide estimation for Sprint planning.

Why should we estimate a User Story?

• So, Scrum team will actually start thinking about the work involved. The subconscious mind will start working on it while the conscious mind is busy doing current work on hand. Multi-tasking without any loss of productivity!
• Your Scrum planning meeting will be quick and effective. You will have more time for asking questions to understand the requirements and deciding on "Acceptance Criteria", test cases etc.
• To calculate team's Velocity per sprint, so that we can forecast project completion, budget etc.
• It will help us to forecast, plan and prepare for production Release planning.

Who estimates a User Story?

• Development team - They will always have the final say because they do the actual work.
• Experienced Product Owner, who is aware of Team's capacity/capability can usually provide initial estimate while writing User stories and ordering Product Backlog items.

When should we estimate a User Story?

• It's a continuous process till the User Story is completed and accepted.
• At the time of creating/writing a User Story.
• During Product Backlog Grooming sessions.
• During Sprint planning session.

When should we calculate a User Story points?

• During Sprint planning session. This will help us to select Sprint Backlog item based on team's Velocity.
• Before Sprint Review meeting, so that we can compare our estimated value with completed actual value. Delays can be explained to the stakeholders.
• At end of Sprint Review meeting, to calculate accepted stories vs delivered stories. The difference will give us information about incomplete work.
• The reasons for deviation can be discussed during Sprint Retrospect meeting to discuss what was missed and how to improve?