If you have been informed about agile methodologies, the word Sprint will be familiar to you. In case this is your first time hearing about this type of methodology, I recommend that you read our article on agile methodologies first, and then come back to this one.

What is a Sprint

It is the essence of agile methodologies. It is a conglomeration of requirements that must be developed during a certain period of time, no more than a month, and be integrated with the final product. It is used both for a new product and to segment it to control the stages of each development, and it is also used to develop evolutionary products and gradually integrate them into the production environment.

“Divide and you will conquer”, is the main motto of segmenting the development of a project in Sprints. They allow you to sequence sets of requirements sequentially, in this way the client knows at all times what functionality will be available at the end of each Sprint. It also allows you to modify the priorities of future Sprints, since the development team is always focused on the current Sprint.

The longer a Sprint lasts, the more requirements will come out at the end but if the client wants to make a change or re-prioritize certain requests, he will have to wait longer since he can only modify future Sprints. The shorter a Sprint lasts, the customer will be able to see constant updates in the production environment but the more non-development time will have to be invested.

The phases that a Sprint contains

It contains 5 phases, some of them are key meetings, to be able to finish a Sprint. They are not rigid phases, it is not necessary that they all follow the same order, only some of them. Then each project adapts its own methodology based on the following structure.

Sprint Planning

It is the first meeting that takes place on the first day of a Sprint. In this meeting, the client must have written the requirements that they want to be developed in the Sprint that is going to start. It is recommended that the client has defined more requirements than he thinks can be included, so that there is a remainder and, in no case, the development team is left without assignment.

In this meeting, the client is in charge of presenting to the development team the list of requirements that he has prioritized for the Sprint that is going to start and the development team has the whole day to make estimates about that list. At the end of the day, the Scrum Master will be in charge of communicating to the entire team the final list of requirements that will be included in the current Sprint based on the available development hours and estimates. Estimates, personally, I prefer to be made both in hours and in Story points (complexity points).

I have worked on projects where the client prepares the desired list of requirements well in advance of this meeting and the development team also estimates beforehand. In this case, the Sprint Planning is a mere procedure to calculate the requirements to include and, on the same day, the development team begins to develop. If it is done in this way, certain hours must be reserved during the Sprint to dedicate them to the estimation of future requirements.

Daily meetings

Daily meetings of no more than 15 minutes in which the client participates (with a role of only listening and answering questions), the Scrum Master and the development team. It is really a meeting made for the development team, so that it reports to the entire team the following points:

• What did you do yesterday
• What are you doing today
• What impediments do they have to move forward?

These 3 questions have to be answered by each of the members of the development team. In case of doubts, the client answers them. In the event that an impediment arises, the Scrum Master is in charge of pursuing the relevant person in order to unlock said impediment.

Sprint Development

It is the time, in days and hours, reserved for the development of the requirements agreed in a Sprint Planning. It is the effective time of the developers, including the internal testing phase.

If a Sprint is 2 weeks (10 days), not all hours are taken as effective for development. The first day is assigned to Sprint Planning, the last day to Sprint Demo and integration with the production environment, and the penultimate day to comprehensive testing. Likewise, it is not advisable to expect that the 8 hours that a working day has are 100% effective for development. Unavoidable activities such as: chat, email, interruptions in the work environment, etc., are part of the process and should not be counted as development hours. If you counted them, it would surely come out at the end of each Sprint that you did not deliver what had been estimated.

Personally, to a working day of 8 hours, I prefer to have 6 effective hours for each developer and leave 2 hours for said activities.

Sprint demo

It is a meeting that takes place on the last day of the Sprint or during the last days. In it, the development team presents the requirements already developed in a test environment so that the client can validate that everything is correct.

You have to be careful with this meeting. Ideally, the development team has done everything perfectly and the client is happy, therefore, during the same day, the evolutions are uploaded to production. But really it's not so. We are human, and for one reason or another there are always points where the client does not agree, either because what was requested was not well understood or because the developer has developed it poorly. In this case, time is needed for correction and resubmission. You can solve this mishap in several ways:

• Reserving certain hours during a Sprint to correct errors from the previous Sprint and have them re-introduce themselves in the current one.
• Leave the last 3 days of Sprint to correct errors and carry out a UAT (User Acceptance Testing) phase in which the entire team is focused on it.

In either of the two solutions you sacrifice development time for correction time. But it is totally necessary and I am already telling you that even though it is a team with a lot of experience and very cohesive, corrections always come out.

Sprint Retrospective

It is the last meeting that is held as a closure of a Sprint. This meeting reviews how the development and compliance with the requested requirements has gone through reports that, today, the vast majority of Sprints web tools already have integrated. Some examples are: Report of requirements included in a Sprint versus requirements delivered. Report on the course of closing requirements as the days have passed (Burndown chart). Team cohesion report: the Story points that they have been able to deliver. You should see a sprint after sprint increase in delivered story points without changing the length of a sprint.

Apart from analyzing these reports, each of the members of the entire team (client, scrum master and development team) must mention the aspects that they think have gone well during the Sprint and the aspects to improve for the following ones. The Scrum Master takes note and adds actions to be carried out to make changes related to the aspects to be improved.

Conclusion

Many people believe that so much meeting and so much bureaucracy only slows down the delivery of the final product and its launch on the market. In certain situations it may delay it, so you should study each case and see if a simpler variant can be implemented. However, the vast majority of times that someone thinks like this, it is usually cheaper and ends up with a better product in much less time than if they apply waterfall methodologies.

The main driver of these methodologies is the agility of being able to make changes midway through development or even change course in record time. One of the most important aspects are the people who make up the team. It is necessary that there is cohesion and a good atmosphere between them, it directly affects the result of the product. In a team in which there is not a good atmosphere, it is recommended to invest in coaches to understand the points to improve and increase cohesion between them.

I hope this article has been helpful to you and do not hesitate to share it on your social networks if you think it can be useful to more people.