Sprints on GitScrum
# What is it and how does it work?
Scrum shows sprints in a simple way to define, which can be understood as the small cycles that make up a project. In each cycle, we have a fraction of the project’s scope and a slice of the schedule. The sprints have some very remarkable features, and it has an extremely important role when planning and managing quick projects.
# Understanding the best practices
Sprints are cycles usually made up by four weeks. It is also common for teams to organize into sprints with a timebox (which is the sprint period) defined for two weeks. At the end of a cycle, another one immediately starts, and so on, until the end of the project.
Have in mind that the sprint in Scrum is much more than a time frame. Some key activities must be performed before the beginning of a sprint, during its execution, and also after it so that the workflow happens efficiently.
# Planning the Sprint
The ground zero of a Sprint is certainly your planning meeting. It is a meeting that can be prolonged, but that shouldn’t last more than four hours for 2-week sprints and 8 hours for 4-week sprints. After all, the entire team will be involved, which makes this meeting a high financial investment for the company, so it is up to the team to make this meeting efficient.
During this meeting, the team must talk about the user stories that make up the project’s current Backlog, aiming to understand, analyze, and define which stories will be developed in the next cycle that is going to start. In the scope selection process that will be implemented, that is, the stories that will be accepted in the sprint, it is very reasonable that the project Backlog is sorted with priorities and estimations for the team to take such information along with the sprint’s time-box, so that the selected work is fair; not more, nor less of what the team can deliver.
# The execution of the Sprint
When the sprint starts running, it is very important that the team is interrupted the least amount of times possible, so that their work happens as planned. The Scrum Master must always be watching for any hindrances in the team, and must always look to solve them as quickly as possible.
The planning meeting has a very important role, and also a very large dedicated time. Another very important meeting in the scrum is the daily meeting that always happens at the beginning of the workday, but it must always have a maximum duration of 15 minutes.
During the daily meetings, the members must give feedback on the work that was performed. It is the appropriate moment for the team to let the Scrum Master know about any problems that might be happening in the project.
# Sprint Revision
After closing the sprint time-box, it must be reviewed, which is a key stage in the cycle. It is during this meeting that the project stakeholders will gather for a moment to analyze and understand everything that was developed during the sprint time-box. In this meeting, the team presents all the stories that were developed, and then following the “definition and done,” the Product Owner must validate the situation of the project. In other words, accept or reject it.
# Sprint Retrospective
The sprint retrospective is the last element before a planning meeting of a new sprint. During the retrospective, the team must analyze and reflect on the goals they successfully achieved, and those that they didn’t, as well as the ways and strategies that worked and didn’t work. In this meeting, they must generate an output that is summarized in a continuous improvement plan for the team, which can have practical actions that lead to high performance. The analyses made during the retrospectives must approach not only the tools and activities, but also the relationships between the people involved in the sprint.
# How to create a sprint
To start creating your sprints on GitScrum, you need to access your project, and then on the upper bar, click on the “Project Options” menu, as shown on the image below by Step 01 and then click on the “Create Sprint” option (Step 02).
When you are visualizing the form to create a sprint, you must provide some data about it, as you can see in the image below.
- Title: The title of the sprint can be whatever your project manager thinks is appropriate. It is very interesting to follow a pattern, so that when the project has a large number of sprints, it doesn’t get confusing.
- Goal: In this field, you can describe what are the main goals of the sprint that is being planned. It is interesting that the information inserted there is clear for all members of the project, facilitating small deliberations regarding the sprint;
- Start: Here you must inform the day the sprint will start;
- End: Finally, the information of when the sprint’s time-box ends.
After filling all the necessary data, just click on the “CREATE SPRINT” button and your new sprint will be registered.
# How to edit a sprint
The process of editing a sprint is very simple and practical. You just need to select, on the side menu, the option “Sprints” (Step 01 shown on the image below), and then you will have your sprint list screen, where you can see all the sprints registered for this project. At this moment, you must select the sprint you wish to edit (Step 02).
At this moment, you must visualize the main page of a screen, and then just select the option “Edit Sprint” (highlighted on the image below), which is available at the upper block with the information and options about your sprint. Then you can modify all the data that were provided during the previous sprint registration.
# How to link a task to the sprint
There are different ways in which you can assign tasks to the sprint on GitScrum. The first and simplest one is to link it on the task directly. When you open a certain task, you can indicate to which sprint that task belongs, as shown below.
If you want to assign many tasks to one sprint, which will usually happen while planning the scope of a new cycle, GitScrum offers a very simple way to assign many tasks at once. You have to, from your project, click on the “Sprints” option on the left side menu, and then choose a sprint among the items presented, as shown in the image below.
Then, you will be on the page of your sprint, where you can see a series of information as well as the project workflow with the tasks in that sprint. For that moment, click on the option “Assign Tasks” (shown below) so that GitScrum leads you to the task assignment page.
At this moment, you will have all the tasks of your project listed on the screen. To assign the desired tasks in this sprint, you must click on the button “Add to this Sprint.” When a task has already been assigned on another sprint, and you wish to switch it to another one, you must click on the “Switch to this Sprint” option, and then, if you wish to remove a task from the sprint, just click on the option “Remove from Sprint.”
# Understanding a sprint’s burndown chart
The Burndown Chart is an incredible tool for project management. Through it, the team can have a faster response time regarding the progress of the schedule and the scope regarding their respective expectations.
The Burndown is initially conceived by the display of the days that make up a sprint on the X-axis of a Cartesian plane. The Y-axis represents the volume of the scope. Also regarding the make-up of the chart, two lines will be shown.
The line that represents the Ideal Burn shows points that represent the maximum work volume (Y-axis) that the sprint can have in progress (that is, not completed) regarding the day of the sprint (X-axis). This way, we will have a decreasing line regarding time. On the first day of the Sprint, we have a high volume of work and a lot of time to spare, and as the time-box advances, the volume of work that can still be pending decreases until reaching zero at the last day of the sprint.
Opposite to the ideal burn, we have a line that is the representation of the Actual Burn, which has the responsibility of demonstrating the work volume regarding time, but now in an ideal environment, but what is truly happening in the daily life of the project. The Actual Burn represents the real pace of the team. On the image below, you can visualize a burndown chart on GitScrum.
When the line of the “Actual Burn” has higher values than the “Ideal Burn,” the chart shows that there is a delay on the project, which can be reflected on the final date for development. When the “Actual Burn” is inferior to the “Ideal Burn,” it means that the team is developing the work in a much faster pace than planned for the project, which at first is good, but it can show a flaw in planning. Pay attention to this and be quick with GitScrum.
On GitScrum, the “Ideal Burn” is represented by the green line, and the “Actual Burn” is represented by the blue line. The main goal of the Burndown is to generate a simple and objective analysis regarding the progress of the project. Therefore, it is recommended that you always make your interpretation.