The following are the basic rules for sprints: sprints are time-bound, usually lasting two to four weeks, team members commit to achieving a sprint goal, no one outside the team is not permitted to make additions or changes. A sprint planning meeting is held at the beginning of a sprint, during which the team and stakeholders establish a goal. Team members participate in daily scrum meetings to share the progress of their work. The team conducts a sprint review meeting at the end of the sprint to demonstrate progress to stakeholders.
A retrospective is held after the sprint review, during which team members discuss how the team worked together during the sprint and discuss ways to improve for the next sprint. For example, in the retrospective meeting, team members might suggest that the team have more frequent meetings to ensure everyone is on the same page and to help keep the sprint on track. Each sprint begins with a meeting between teams and stakeholders to plan the next sprint. Two meetings are required to prepare a sprint: a sprint prioritisation meeting and a sprint planning meeting.
A priority-setting meeting aims to prepare, or “groom,” the product backlog and to identify a possible sprint goal. After the sprint planning meeting, the sprint backlog is created, outlining the work the team commits to completing in the next sprint. During the sprint prioritisation meeting, the team discusses the goals and objectives for the upcoming sprint and determines the order in which tasks should be completed. The team then agrees on the sprint goal and creates user stories to guide the development of the sprint backlog. The sprint planning meeting is the final step before the actual sprint begins, where the team finalises the sprint backlog and agrees on the tasks that will be completed in the sprint.
In the sprint prioritisation meeting, we review the high-priority items on the product backlog and identify a potential sprint goal. During the meeting, the product owner describes the most essential features. Team members need to understand each PBI. A team may be unable to tackle high-priority PBIs in a single sprint when they are too large. To accommodate these features, they are broken down into smaller PBIs. As a next step, the team discusses potential sprint goals. Based on the team’s current composition, the team selects the most critical PBIs from the product backlog. After approximately two sprints’ worth of PBIs have been discussed, it’s advisable to end the prioritisation meeting. In addition, a PBI may be skipped when it depends on another team. While avoiding such dependencies in the product backlog, they sometimes occur.
There has been no commitment to work at this time. The planning meeting identified the PBIs the team may be able to accomplish, but the team is only ready to commit once their PBIs are broken down into individual tasks.
Once the team has identified potential PBIs for the sprint, each task is broken down one by one into the sprint backlog. The sprint planning meeting is where this occurs. All team members are invited to attend this meeting, including the Scrum Master and product owner, and any domain experts who may help solve problems or answer questions. Scrum Masters help teams identify constraints that might impact their ability to meet their sprint goals at the beginning of the meeting.
These constraints include the following such as, reduced time available due to holidays, members of the team who work away from the team, other areas that may have an impact. It is primarily their past performance that determines the team’s ability to commit to work. An effective way to determine this is to examine how the team has performed in previous sprints. In the planning meeting, this becomes the limit of the sprint backlog. Afterwards, team members discuss details of each PBI that could be included in the sprint goal. In this discussion, the product owner’s attendance is crucial since there are many subjective aspects to consider. Once the PBIs have been broken down into tasks, the team begins to work on them. Breaking down the highest-priority PBI from the product backlog into tasks is the first step in creating the sprint backlog. Design questions are raised at first, and everyone is involved.
The team writes the feature requirements to estimate how long each task will take to complete. In discipline groups, tasks are estimated. A team of four programmers, for example, estimates programming tasks together. In a single-programmer team, each programmer estimates all programming tasks independently. Tasks are estimated in hours. Estimates are in ideal time, which is how long a task should take without interruptions. A one-day task is different from an eight-hour task. Usually, eight-hour tasks take more than one calendar day to complete. Every day, there are interruptions, problems, and conversations. A big task’s estimate is less accurate than a minor task’s estimate. It’s easy for me to estimate how long it will take to get to the local store, but a cross-country drive will take longer. Each task is manageable, but 16 hours is reasonable before it needs to be divided. Team members might need more information to break down tasks of more than 16 hours into smaller parts. The task will be placed on hold until they have more information and are ready to work on it. A PBI’s estimated hours are added after each task is broken down.
In the sprint backlog, the remaining hours are compared with this total. Team members commit to completing that revised PBI if there is room for it on the sprint backlog. A project should include contributions from every speciality. The team doesn’t commit to the work if the PBI exceeds the sprint backlog. When this happens, you have three options. The PBI is then returned to the product backlog, and a smaller one is added. Second, the original PBI could be broken up into smaller ones. A subset of the original PBI may fit into the sprint.
It is possible to divide a PBI into two parts, one for each half of the level. Drop an item already pulled in to allow the upcoming item to fit. The product owner’s responsibility is to help the team decide which approach is the most appropriate. Sprint backlogs should not be filled at the last minute. It is usually during sprints that forgotten tasks are discovered. Adding another feature to bring the remaining hours down to zero is unnecessary if the remaining hours are small (about a day or two). It’s never a problem to find a few hours for additional polishing!
A sprint typically lasts two to four weeks, depending on several factors such as: how often customers provide feedback and make changes, a team’s level of experience, the duration of reviewing and planning, sprint planning capability, team intensity during the sprint. In addition to these factors, sprint length may change over a project. In general, the duration of a sprint depends on how long stakeholders can wait before seeing progress and providing direction. As early stages of game development require frequent feedback, a shorter sprint is needed to ensure the game is heading in the right direction. Feedback on the character’s motion, the camera’s behaviour, or the controls’ layout might be needed. The production team, for example, does not require such a rapid feedback cycle, so a longer sprint is preferable. During the sprint, the goal cannot be changed. Shortening the sprint may be necessary if stakeholders feel that four weeks is too long to wait for a review.
New teams unfamiliar with game development, agile development, or working together should begin with shorter sprints. As a result, they can learn how to develop iteratively and incrementally. The practice of long sprints should be discouraged for new Scrum teams because they tend to treat sprints as mini-waterfall projects. The team will spend two days exclusively doing design, a few weeks creating code and assets, and finally, integrating, testing, and tuning in the final few days of the sprint before crunching during the last few days. Since little time is left to iterate and polish their work, they will need more time to achieve the best possible result. These activities are performed more in parallel by experienced teams who continuously design, code, create assets, test, and debug. Iterating more during the sprint produces better results and allows the team to increase the value of their work.
Team planning and review meetings often consume a significant amount of team time during short sprints. No matter the sprint length, reviewing and planning usually takes substantial time. Although sprint planning may take less time, the remainder of the day is never 100% productive following the meeting. If you had a sprint lasting one week, you would likely spend one day reviewing and planning that week. That would be 20% of the team’s time.
The majority of product owners limit sprints to four weeks to be able to monitor progress over time. Much progress in some technical areas (such as engine or pipeline development) cannot be achieved in as little as four weeks. Longer sprints usually indicate that technical practices need to be improved. It is essential to address any development method that cannot demonstrate progress at least once a month. An interim goal should show that risk has been reduced and that it is valuable. A team’s potential waste increases the longer it spends without proving or disproving architectural assumptions.
Stakeholders and Scrum teams determine sprint duration. The final say goes to the product owner—only change sprint length between sprints, not too often. Varying sprint lengths frequently is disruptive. To estimate the appropriate sprint backlog, the team takes some time to adjust to a particular sprint length. Team members must share progress updates and identify impediments during sprints. For the team to make the right decisions, they need the correct information. The sprint backlog needs to be easily accessible. To achieve their goals, they must understand where they stand. They need to recognise when they cannot attain their goals as early as possible. The Scrum methodology provides teams with this information through several low-tech practices and artefacts. Various tracking tools, such as task cards, burndown charts, task boards, and war rooms, have proven extremely useful in tracking sprint progress.
Many methods are available for recording and tracking tasks. The most effective way to organise tasks is with task cards, which are 3-by-5 index cards. There are many advantages to using these cards over other tools. As a result, all team members can participate in the creation and management of tasks. Customising the task card using various colour cards and markings is possible. To help them better prioritise their tasks, a cinematics team used stamps with pictures of fruit to categorise the order of asset creation tasks. A priority was given to picking the “low-hanging” fruit.
According to the sum of the estimated tasks expected to accomplish the sprint goal, the team commits to achieving the sprint goal during the planning meeting. To assist in tracking progress toward their goal, the team updates the estimate of work remaining daily. A burndown chart is used to plot this day-to-day measurement. Teams use burndown charts to assess whether their efforts lead to achieving their sprint goals.
According to the planning section, tasks are estimated according to “ideal” work hours. As the name suggests, an ideal hour is a period of uninterrupted work without interruptions, bug fixes, tool problems, questions, coffee breaks, friends on the phone, etc. With all the competition for our time and attention, we are lucky to complete four ideal work hours in an eight-hour workday. Burndown charts indicate the number of ideal hours to accomplish a sprint goal. Known as a burndown trend, it describes the rate at which ideal hours decrease per day. Scrum teams can benefit significantly from measuring this trend. Using the burndown trend, the team can monitor their progress towards achieving their sprint goal. The team must understand that the goal is to achieve something other than the ideal burndown line. To measure their progress, they can use the burndown chart to see how they do each day.
During a sprint, the task board displays the goal, burndown chart, and tasks for the sprint. The team gathers around it daily and pulls the work they need to complete. Often, the task board occupies a significant portion of a wall. As work on each task card is initiated and completed, the card moves from the “not started” column to the “done” column. In addition to adding the burndown chart to the task board, this move visually represents the sprint’s progress. A task board should have at least four columns.
According to the first column, the team has prioritised its PBIs. The second column contains a list of tasks that have yet to be completed. These two columns are created following the sprint planning meeting. All tasks in progress are listed in the third column. To coordinate their efforts, team members move the associated task card from the second to the third column as they decide what they will be working on next. All completed tasks are listed in the last column. As team members complete tasks, their cards are moved into this column. There is typically a row for each task with its corresponding PBI. By doing so, the team can quickly understand how each feature progresses. Teams may add columns to their task boards to represent additional task states. In addition to the in-progress and completed columns, they may add a pending column for tasks needing external approval before moving to the “tasks completed” column.
