What Are The Events In A Scrum Team?

Google+ Pinterest LinkedIn Tumblr +

Trying to implement Agile and Scrum into your organisation?

Trying to run Scrum the right way?

What are the intended outcomes of a daily Scrum?

What is the maximum length of a Sprint?

Keep reading…

Scrum contains five main Events. The Sprint is a Timeboxed Event that contains the other four Events. The Sprint Planning meeting is the first Scrum Event at the beginning of every Sprint. The two main objectives of the Sprint Planning meeting is what is going to get built during the Sprint and how it will be developed. The Daily Scrum is a 15 minute meeting that occurs at the same time and place every day. This is held by the Development Team and answers the questions “what did you work on yesterday, what are you working on today, and are there any roadblocks?” The Sprint Review is used so the Development Team can demonstrate the work completed during the Sprint to the customer to get feedback. Finally, the Sprint Retrospective is used to review the Sprint and make any improvements before the next Sprint. These meeting should be held in the same time and location so as to maximize efficiency of the Scrum Team. Where possible, the Scrum Team should be located in the same geographic location so as to share information more easily.

Timeboxing

A Timebox is the maximum amount of time a Scrum Event can take. Each Event has a different maximum Timebox depending on varying factors. Once the Sprint length has been determined, the Duration of each Timebox for each type of Scrum Event should be determined. Once set, these should not be changed with the exception of new information becoming available via the Sprint Retrospective.

Sprint Planning

Each Sprint should have a goal that is aligned with the overall project objectives but also focuses the Scrum Team on the tasks immediately at hand. The primary purpose of all Sprints is to deliver “potentially releasable” pieces of software. When starting a project using the Scrum framework, the first Scrum should start with Scrum 1. There is no Scrum 0 that is designed for setting up either the team, hardware, software, or other requirements. All efforts to establish the Sprint Team along with the necessary equipment is completed along the way and as the need arises. When establishing the first Sprint Planning meeting, the Scrum Team should set the maximum Timebox for all Sprint Planning meetings. Scrum allows a maximum of eight hours for a Sprint Planning meeting for a one month Sprint. For a Sprint lasting two weeks, the team would hold a Sprint Planning meeting no longer than four hours.

Prior to the Sprint Planning meeting, the Product Owner should have groomed enough Stories in preparation of the Sprint Planning meeting. The Stories should have the correct description, be ordered according to their value to the business, have an appropriate value set, and have an estimation set by the Development Team. Each Story should also have a “definition of done” so the Scrum Team can determine if the software created fulfills the requirements set in the Story. It is not the responsibility of the Scrum Master or Product owner to tell the Development Team what they should work on. The Development Team will determine which of the Stories it thinks it can complete in the next Sprint and move the Stories from the Product Backlog to the Sprint Backlog. The Development is responsible for and manages the Sprint Backlog. From there, the Stories are broken down further into Tasks and assigned to one of the developers for completion. While a number of Storied are moved from the Product Backlog to the Backlog, not all of the Stories need to be broken down into Tasks at the beginning of the Sprint. Only enough Stories need to be broken down at the beginning of a Sprint so the Development Team can start work. As they progress through the Sprint, they will break down each Story into Tasks.

During the meeting the Development Team should determine:

  • What should be built during the Sprint and
  • How it should be built keeping in mind the Sprint goal

Sprints

A Scrum Team is guided by the project’s overall goal. In order to achieve the project goal the Scrum Team breaks down the workload into Sprints. Sprints are Timeboxed events. The length of a Sprint is set at the beginning of the project and does not change. Scrum suggests a Sprint can be as short as a week  but should not be longer than one month. Agile suggests a Sprint can be as long as two months. The longer the Sprint, the more complexity and risk is introduced into the Sprint. Additionally, a Sprint should not be set too short as the Development Team aims to deliver “potentially releasable” pieces of software. If a Sprint is set too short i.e. one week, the Development Team may not have sufficient time to complete the necessary work. Most teams timebox their Sprints between two to four weeks.

During each Sprint, the Product Owner orders the Product Backlog according to the greatest value to the business. The Product Owner and the Development Team work together to chooses which Stories should be worked on during the Sprint. Enough Stories should be moved from the Product Backlog to the Sprint Backlog so the Development Team can complete them during a single Sprint. An Increment is a “potentially releasable” piece of software that makes up part of the larger project. The Increment is the output of all the Stories from several Sprints. The software may not be released for use but it must be “potentially releasable.”

Once a Sprint has started the Stories within the Sprint Backlog should not be changed. The only exception to this is if the Development Team has underestimated their capacity during the Sprint Planning meeting and has the time and resources to add more Stories to the Sprint Backlog. A Product Owner is the only person who has the authority to cancel a Sprint. If a Sprint is cancelled, the “done” Stories are moved to the Increment and the incomplete Stories are moved from the Sprint Backlog back to the Product backlog and reassessed based on the changed conditions.

Daily Scrum

Because Scrum is an adaptive way of working, it lacks the more robust structure of other project management frameworks. As such, there needs to be a way for the Scrum Team to coordinate and synchronise their work. The Daily Scrum is a 15 minute Timeboxed meeting that occurs at the same time and place every day. The purpose of the meeting is so each member of the Development Team can answer three questions:

  1. What did I work on yesterday?
  2. What am I working on today?
  3. Are there any roadblocks?

Once these questions have been answered the Development Team will have a clearer idea of how it is progressing and whether or not it will complete the Sprint as planned. While not a status meeting, the Development Team should make note of it’s progress using something like a burn-down or burn-up chart. The burn-down/burn-up chart can be updated at the end of each Daily Scrum to keep all members of the Scrum Team up to date as to the progress of the current Sprint. Realistically, any tool used to manage a software development team will have and automatically calculate the burn down/up charts.

If any roadblocks are mentioned, the Development Team can discuss these in more detail after the Daily Scrum meeting. In addition, they can mention these roadblocks to the Scrum Master as it’s their responsibility to assist the Scrum Team in removing road blocks. If needed, the Scrum Master can also facilitate the meeting. While anyone can attend the Daily Scrum meeting i.e. Scrum Master, Product Owner, SME, Business Owner, only the Development Team are the ones that actually participate.

Because I work in a remote team, it’s difficult to have a daily standup at the same time and same place every day. To work around this, I created a Daily Standup Meeting Confluence document which the Development Team completed every morning so I could review it as soon as I came online. In addition to the three questions being answered, I also added a “weekly cost” column so I could track my development expenses.

Sprint Review

The Sprint Review meeting is a Timeboxed Event. For a one month Sprint, the Sprint Review has a maximum allowed time of four hours. Shorter Sprints can accommodate shorter Sprint Review meetings. The purpose of the Sprint Review meeting is so that the Sprint Team can demonstrate the work completed to stakeholders, gather feedback and collect change requirements. This process allows the solution being delivered to be inspected and changes made incrementally, therefore reducing overall project risk and increasing the chances the finished product will be in line with the requirements of the customer. Only Stories that have met the definition of “done” are presented during the Sprint Review meeting. No partly completed work is demonstrated. Once the feedback is captured, the Scrum Team collaborate to incorporate the collected information into the next Sprint. Any Story in the Sprint Backlog that has not been completed is moved back to the Product Backlog. The Product Owner will refine the Product Backlog in preparation for the next Sprint Planning meeting, where the Development Team will decide which Stories to work on in the next Sprint. While the Development Team is responsible for measuring the progress of the Sprint Backlog, the Product Owner is responsible for measuring the progress of the whole project.

Sprint Retrospective

The Sprint Retrospective is typically three hours for a one month Sprint. Shorter Sprints can accommodate shorter meetings. The purpose of the Sprint Retrospective is for the Scrum Team to gather lessons learned from the recently completed Sprint with the aim of improving future Sprints. This meeting is a formal opportunity for all Scrum Team members to assist in the way the team performs although opportunities for improvement are not limited to just the Sprint Review meeting. All suggestions of how to improve the Sprint process are welcomed regardless of how big or small the suggestions are. Below is an example of a Retrospective meeting in my Confluence instance. Typically, I add information into this throughout the Sprint so I don’t forget. At the end of the Sprint, I reflect more deeply on how the Sprint was managed and add additional information as needed.

I hope you’ve found this definitions and explanations of Scrum Events beneficial. If you have any questions feel free to get in contact or leave a comment below.

Share.