As we promised in our previous article, Roles in Scrum, we’re following up with a related article on Events in Scrum.
The Scrum events are:
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
An iteration in Scrum is represented by a Sprint which is a basic unit of development. Scrum divides time into Sprints. It can take between one week and one month and after each sprint the product is in a stable state and it can be delivered to the market.
In Scrum, the sprint planning meeting is attended by the Product Owner, Scrum Master and the entire Scrum team. Outside stakeholders may be invited to attend, although this is rare in most companies because they would not be participating in decision-making processes.
During the sprint planning meeting, the Product Owner describes the highest priority features to the team using the Product Backlog Items. The team needs to ask enough questions so that they will be able to turn a high-level user story of the Product Backlog into the more detailed tasks that will be added in the Sprint Backlog.
The Team and Product Owner must state the acceptance criteria for each User Story, which will then be added to the Acceptance Tests used by the developers.
The Product Owner [PO] doesn’t have to describe every item being tracked on the Product Backlog. A good guideline is for the PO to come to the Sprint Planning Meeting prepared to talk about maximum two sprint’s worth of product backlog items.
The Sprint Planning Meeting should result in :
- A sprint goal
- A sprint backlog
A Sprint Goal is a short description of what the team plans to achieve during the Sprint. It is written collaboratively by the Team and the PO. It represents the objective of the Sprint.
The other output of the Sprint Planning, the Sprint Backlog, contains the list of Product Backlog items that the team commits to deliver during the Sprint. All of the User Stories are assigned and the team estimates a time-frame for each of them. The most important point here is that it’s the team that determines how much work they will be able to do during Sprint.
One of the key advantages of adopting Scrum is the ability of the team to assess new work loads effectively using different techniques like: Planning Poker, T-Shirt Sizes, Relative Mass Valuation, Story Points or Fibonacci numbers.
Image source: agilemarketing.net
On each day of a sprint, the team holds a scrum meeting called the “Daily Scrum” or Standup Meeting. Meetings must be held in the same location and at the same time each day. Ideally, a daily scrum meeting is held in the morning, as it helps set the context for that day’s work. Scrum meetings are strictly time-boxed to 15 minutes. This keeps the discussion short and relevant and updates the entire team on the Sprint’s status.
The Daily Scrum meeting shouldn’t be used as a problem-solving or issue resolution meeting. All identified issues are taken offline and usually solved and discussed after the meeting. This type of meeting helps maintain open communication within the Team, it’s not meant for micromanagement, nor as a planning meeting or technical discussion. During the daily scrum, each team member answers the following 3 questions:
Image source: http://www.quickscrum.com/
After each Sprint the Team should deliver a product increment. This means that at the end of each sprint, the team has produced a coded, tested and usable piece of software that meets the Definition of Done (DoD).
Definition of Done is a simple list of activities that add verifiable/demonstrable value to the product. It can include writing code, coding comments, unit testing, integration testing, release notes, design documents, etc.
DoD value can be added at various levels:
- Definition of Done for a feature (story or product backlog item)
- Definition of Done for a sprint (collection of features developed within a sprint)
- Definition of Done for a release (potentially shippable state)
At the end of each sprint, a sprint review meeting is held. During this meeting, the Scrum team presents what they accomplished during the Sprint, in what essentially is a demo of the new features.
The Sprint Review Meeting or Demo Meeting is intentionally kept very informal, without using slides or another tool to show the work done allowing no more than two hours of preparation time for the meeting.
The Product owner, the Scrum team, the Scrum Master, management, customers and developers from other projects may attend the Sprint Review meeting.
During the Sprint Demo all the items on the Sprint Backlog are discussed. Ideally, the team would have completed each item, but it’s more important that they would have achieved the overall goal of the sprint.
After the presentation, the Product Owner decides whether or not the Sprint Goal was achieved and if the Sprint result is accepted or not.
After the Demo Meeting, the team holds a Sprint Retrospective Meeting. It is usually the last meeting in a Sprint and can take about an hour. The team, the Scrum Master and the Product Owner participate at this meeting.
After each Sprint there are always improvement opportunities. A good Scrum team will be constantly looking for ways to improve their performance and processes and this the general purpose of the sprint retrospective meeting.
Although there are many ways to conduct this type of meeting, our way to do it is to use a simple classification of the ideas and feedback: start – stop – continue doing. This is perhaps the simplest, but often the most effective way to conduct a retrospective. Each team member will be asked to give several examples for each category:
- Start doing
- Stop doing
- Continue doing
After an initial list of ideas has been created, the team members will vote specific items to focus on during the next Sprint. At the end of the Sprint, the next retrospective often starts with reviewing the list of items selected in the prior Sprint Retrospective.
Image source: http://imgbuddy.com/scrum-retrospective.asp
All these 4 meetings are important to help the team organize, evaluate and adjust the process. Everybody knows that experience is the best teacher, and the Sprint is designed to provide you with multiple opportunities to receive feedback during these meetings, from the Product Owner, from the Team members and from the market, and most importantly it provides you with the opportunity to learn from this feedback. What you learn while working on one Sprint helps you prepare the next one. In Scrum, we call this “inspect and adapt”, but you might call it “continuous improvement” – either way, it’s a beautiful thing to be a part of.