Scrum Events

All the Scrum Events are time-boxed events i.e. every event has a maximum duration. Once a Sprint begins, it’s  duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved.

Other than the Sprint, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something

Scrum has five events

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective
• Product Backlog Refinement

Sprint

The heart of Scrum is Sprint - a Time-Boxed effort ranging from 1 to 4 weeks. As shown in the diagram above, it is an iterative development cycle. As Sprint is Time-Boxed, it cannot be extended than the planned end date, whether the work planned for that Sprint is completed or not. If work for some of the items planned for a current Sprint is not completed then those items are pushed for the next Sprints but the current Sprint is not extended. Also, no disturbances are allowed during the Sprint in terms of resources as well as the items selected for the Sprint. No new Items are added during the Sprint. Sprint embraces change for next Sprints. At the end of the Sprint, the Development Team delivers Potentially Shippable Product Increment. The Product Increment should be fully implemented, tested and free of known issues. It should be integrated and deployed on Production near environment.

Each Sprint may be considered a project with maximum a one-month horizon. Like projects, Sprints are used to accomplish planned tasks. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.

Sprints are limited to maximum one calendar month. If a Sprint’s duration is too long, the definition of what is being built may change, complexity may rise, and risk may increase. Sprint gives an opportunity for an inspection and adaptation of progress toward a Sprint Goal at least every calendar month. It limits the risk to maximum one calendar month of cost.

Sprint Planning

The Sprint Planning meeting is conducted at the beginning of each Sprint. The work to be performed in the Sprint is planned at the Sprint Planning meeting. This plan is created by the collaborative work of the entire Scrum Team.

Sprint Planning answers the following:

• What can be delivered from the upcoming Sprint?
• How will the work, needed to deliver product increment, be achieved?

Sprint Planning Meeting is divided into two distinct sub-meetings.

1. Sprint Planning Part One - What
2. Sprint Planning Part Two - How

Sprint Planning is a Time-Boxed event. Each part is time boxed to maximum 1 hour per week of Sprint. 

Participants for Sprint Planning Meeting are:

• Part One - Product Owner, Team, Scrum Master
• Part Two - Team, Scrum Master, Product Owner(Optional)

Sprint Planning Part One

In Sprint Planning Part One meeting, the Product Owner and the Team review the high-priority items from the Product Backlog that the Product Owner is interested in developing in the current Sprint. Usually, these items have been well-analyzed in a previous Sprint (during Product Backlog Refinement), so that at this meeting there are only minor last-minute clarifying questions. 

In this meeting, the Product Owner and Team discuss the goals and context for these high-priority items on the Product Backlog, providing the Team with an insight into the Product Owner’s thinking. Part One meeting focuses on understanding what the Product Owner wants and why those features are needed. At the end of Part One, the Product Owner may leave the meeting but make sure he must be available during Part Two of the meeting if there are any queries to answer.

Sprint Planning Part Two

Sprint Planning Part Two focuses on how to implement the items that the Team decides to work on. The Team selects the items they can complete by the end of the Sprint, starting at the top of the Product Backlog. It is the Team which decides how much work it can complete in a Sprint rather than somebody assigning the tasks to the Team. This is the beauty of Scrum. As the Team selects the items based on its analysis and capacity, it gives more realistic forecast of what can be delivered at the end of the Sprint. From the Product Owner’s prospective, as the Team is selecting items from the top of the prioritized Product Backlog, the Team will be working on the most important items. Team can also select some of the lower priority items if they think that they have some capacity and these items can easily fit. In this scenario the Product Owner is consulted before adding lower priority item to the Sprint Backlog.

The Product backlog items selected for the Sprint are called Sprint Backlog. Team pulls items from the Product Backlog into Sprint Backlog until Sprint Backlog is full. The Sprint Backlog also contains defects and unfinished work of previous Sprint.

In this meeting, the  Team does designing and planning of the tasks needed to convert the Product Backlog into a working product Increment.

By the end of the Sprint Planning meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Product Increment.

During this meeting Sprint Task Board is updated with the User Stories and the tasks to be worked on for the planned Sprint.

Daily Scrum

The Daily Scrum is a 15-minute time-boxed event for the Development the Team is to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next Daily Scrum. The Daily Scrum is held at the same time and same place each day to reduce complexity. During this meeting, the Development Team members answer three questions

1. What has been completed since the last meeting?
2. What will I be doing today?
3. What are the impediments in my way?

The Development Team uses the Daily Scrum to inspect progress towards the Sprint Goal and towards completing the work in the Sprint Backlog. All the Team members attend this meeting. To keep it brief, it is recommended that everyone remain standing.

Daily Scrum is not a Status Meeting where everyone gives a status to Scrum Master. It is an opportunity to discuss the progress towards the Sprint Goal and impediments if there are any. One of the team member or the Scrum Master makes notes of the impediments and the Scrum Master is responsible to help the Team on these impediments. Apart from the above mentioned questions, there should not be any in-depth discussion. If detailed discussion is required then separate meeting is scheduled. During Daily Scrum Meeting, Team updates the Sprint Task Board and Burndown Chart.

Here are some of the guidelines for Daily Scrum Meeting.

• The Team should not report to one person  i.e. Scrum Master 
• Talk Loudly 
• Run at the same time everyday
• Start on time
• Always run it
• Keep to the point
• Keep it short

Tracking the progress during the Sprint

The Scrum team is self-managing and in order to do this successfully it must know how it is doing. Every day the team members update their "hours remaining to complete their task" in Sprint Backlog. One Team member adds up the hours remaining for all the team members and draws a Burndown Chart. The Burndown chart has two lines, one ideal line and the other actual line. The Ideal line shows the Ideal Efforts Remaining for each day to complete the Sprint tasks. This line moves downward and ideally on the last day of the Sprint it reaches to "Zero Hours Remaining". The Actual Efforts Remaining line shows the Actual Efforts Remaining to complete Sprint Tasks. If this line is below the Ideal Efforts Remaining line then the Team is performing well and will complete the Sprint Backlog Items on or before the Sprint end date. If the actual line is above the ideal line then the Team is not doing well and Team may not complete all the Sprint Backlog Items on the last day of the Sprint. In the second scenario, the Team has to take corrective measures so that it can achieve the Sprint goal. The important point of Burndown Chart is that it shows the progress of the Team not in terms of the “hours spent by the Team” but in terms of the “hours remaining to complete the tasks”. If the Team is using some tool to track its efforts then the tool generates the Burndown chart automatically.

Sprint Backlog:

Sprint Burndown Chart:

Burnup Chart

There is one more chart to track the progress of the project towards completion – the Burn up Chart. Typical the Burn up chart has two lines.

1. Total Work Line(Total Scope)
2. Work Completed Line

In this chart the vertical lines represent the total work. In Scrum it is measured in terms of Story Points. The horizontal line represents the time generally in terms of number of days. The total scope line represents the total scope of current Sprint and the work completed line represents the work completed on each day. The distance between these two lines is the amount of work remaining for the completion of Sprint. When these two lines meet, the Sprint will be completed. Regular monitoring and analysis of this chart helps you to identify the problems and take corrective action. 

Sometimes a third line is added to this chart – the Ideal line. This line shows ideal work to be completed for the completion of project on a given date. If the actual line is above the ideal line then your project is ahead of the schedule and when the actual line is below the ideal line then your project is behind the schedule.

If you are using a tool like the Jira to track your project efforts then these tools can create Burn up chart for you.

Sprint Review

A Sprint Review is held at the end of the Sprint to inspect the Product Increment and adapt the Product Backlog. During the Sprint Review, the Scrum Team and stakeholders discuss about what was done in the Sprint. This is an informal meeting, not a status meeting. It is an opportunity for the Product Owner to review the Product Increment and give feedback. It is the time for a Product Owner to understand what is going on at the Development side and for the Team to understand what is going on with the Product Owner and Business side. An Important element of the Review is an in-depth conversation between the Team and the Product Owner. While inspecting the product increment there should not be a slide show but the actual hands on the product increment by the Product Owner or end user. 

Duration of this meeting is one hour maximum per week of Sprint.

Sprint Retrospective

The Sprint Review inspects and adapts the Product Increment whereas the Sprint Retrospective inspects and adapts the process and the environment. During this meeting three questions are asked with respect to the process.

1. What is working well?
2. What is not working well?
3. What are the Action Items for future Sprints?

The Scrum Master facilitates this meeting but many a times it is recommended that the Scrum Master from the other team facilitate this meeting.

By the end of the Sprint Retrospective, the Scrum Team should identify the improvement areas with respect to the process. Those improvements should be implemented for next Sprints - inspection and adaption at the process level. Though the improvements can be implemented at any time, the Sprint Retrospective is a formal opportunity for inspection and adaption process.  

Duration of this meeting is 45 minutes per week of Sprint.

Product Backlog Refinement (Backlog Grooming)

While working on current Sprint Items; some percentage of the Sprint time should be dedicated to refining (or “grooming”) of the Product Backlog items. The Backlog Refinement includes detailed requirements analysis, splitting large items into smaller ones, estimation of new items, and re-estimation of existing items. The Backlog Refinement should be conducted near the middle or end of the Sprint, so that the Team, the Product Owner and other stakeholders have additional information to update the items in the Product Backlog.

This refinement activity is not for the items selected for the current Sprint; it is for the future items, most likely in the next one or two Sprints. 

Duration of this meeting should be no more than 10% of the total capacity of the team for that Sprint. 

Activities performed in this meeting are 

• Ensure the backlog is DEEP
• Re-estimate User Stories
• Update User Stories with new details
• Split User Stories into smaller ones
• Discuss technical risks
• Re-prioritize the items in Product Backlog