In Agile methodology, the work on product development is divided into smaller increments. It is a true blessing for all developers. Why? Because it provides a wide array of benefits. However, to enjoy them all, first one needs to learn how to properly conduct those manageable pieces, so they stay truly manageable! Therefore let me shed some light on sprints in the Agile software development life cycle.
What is a Sprint in the Agile software development life cycle?
Sprint is the term used to describe the basic increment measure used in Agile methodology. It is a certain (agreed-on) period during which a specified work or set of tasks is completed and ready for review. In other words, the Agile team agrees on performing a set part of the project within a specific time. How long is it? It depends on a Scrum Master who manages the workflow in the Agile team. It will usually be roughly a four-week-long phase.
Why do we use Sprints?
The main purpose of Sprints is to make space for improvements. It is especially important in the case of complex projects. Let us look at a specific example. The team develops a booking application for three types of accommodation. At the start, the client chooses a certain functionality according to which the booking will be conducted. The agile team creates the app for one type of accommodation during the first Sprint. The client then says that they wish to change the functionality. The team adjusts to clients' wishes effortlessly in the next Sprint.
Now, imagine the team does not work in a Sprint, and they decide to build the whole app with all the functions and dependencies straight away. Firstly, it takes a long time before the client sees the first results. Secondly, it also takes longer to adjust the whole product to the new requirements.
The takeaway is that the Sprints allow adjusting work to the changing objectives. What else can the team benefit from?
- boost in concrete thinking - the objectives of every Sprint are clearly stated, so the focus is on them and does not get easily shifted
- improvement of prioritizing - everyone knows what to work on, so the team stays focused
- engagement in the decision-making - all members have the say in the objectives of a Sprint and can better understand how choices are made
- boost in productivity - fixed time frame helps to focus on performing work timely
How to plan a perfect Sprint in the Agile software development life cycle?
Understandably, Sprints need careful planning for them to be effective. Such planning happens during Sprint planning meetings. What do they look like? Let me illustrate it with the use of a Sprint planning agenda.
The value of the Sprint (WHY)
The product owner, who is usually the client, presents their idea regarding the goal of the given Sprint. Then, the discussion starts about the direction the development should take to bring the product optimal value at this point. Of course, the goal is not set in stone, and the discussion aim is to define the goal the team agrees to work on. Such a goal should be defined according to SMART (Specific, Measurable, Attainable & Relevant) criteria.
The choice of tasks (WHAT)
The next step is taken by the developers. Once they have the goal, they can start identifying the task that will help to achieve it. At this point, it is crucial to mark specific tasks and prioritize them. Also, main dependencies or blockers should be identified.
The ways of work (HOW)
The next step after agreeing on what to do is deciding how to do it. The developers come up with a specific development plan and structure for monitoring the progress (for example, daily meetings). During such meetings, they will answer questions, such as: what has and will be done, which tasks will be performed by who, what possible problems were (or could be) encountered, and who needs help with which tasks.
It is a good idea to prepare a Sprint planning summary. Such a summary can contain the following elements:
- Setting up Sprint Goal - After the discussion, we agreed upon obtaining 'XYZ' as a sprint goal;
- Picking up items from backlog to current Sprint - To obtain Sprint Goal we discussed & refined XX backlog elements and pushed them to the Current.
- We agreed that we need to focus on item XYZ due to dependencies and blocking possibilities.
- Selecting priorities for the +1 sprint and Research sprint - After discussion, we have picked up XX new elements for the +1 sprint and research Sprint, that seem to be most important in the next development phase (to be discussed in detail at the next Sprint Planning).
What are Sprint Reviews?
As the name indicates, Sprint Reviews evaluate the outcome of Sprints. During the Sprint Reviews the team:
- present the achievements of the Sprint
- give feedback regarding the new implementations
- make plans regarding the product goal (to align with it or adjust it).
A crucial feature of Sprint Reviews is the importance of the whole team's participation. All team members are involved in the creation of the product, therefore all of the members can share their points of view on the past Sprint. It is a crucial task, to make sure Sprint Reviews do not resemble Scrum Master's presentations. They are not the type of meetings that 'should have been emails'. The whole point is to engage the entire team, get valuable input, and conduct future sprints in a way that guarantees the creation of the best product for your client.
What should Sprint Reviews look like in the Agile software development life cycle?
How to make the most of Sprint Reviews? Let's take a look at an example of a Sprint Review agenda below:
Demo
It is a kind of introduction that presents the developed features and performed tasks. This part should be presented by a non-technical user so that the client, who might not be too fluent in technical matters, can understand what Sprint consisted of.
Feedback session
During the feedback session, the team discusses several aspects of the Sprint. Let's analyze the aspects based on specific questions the team should try to answer:
- developed features, performed tasks: Is the quality of developed features/performed tasks up to standard? Did the Sprint result in obtaining the Sprint Goal?
- non-developed features, non-performed tasks: Was the estimation of tasks or features correct? Was the Sprint planned properly? Did the change of scope, task specifications, or Sprint goal happen during the Sprint?
- identification of issues to be addressed at Sprint Retrospective: Was the quality of Scrum events low? Was there a lack of feedback or a miscommunication between the client/customer/Product Owner and the team? Was the quality of backlog items specification or prioritization low?
Product Backlog Adjustments
This phase of Sprint Reviews should focus on the strategy for future sprints to improve the processes. The team asks questions, such as:
- What to do about the features that were not developed or tasks that were not performed (Backlog/ left in current/technical debt, etc.)?
- Should the feedback be refined into possible new Product Backlog items? How to adjust the product goal/strategy?
Similarly to Sprint planning, Sprint Reviews should also have a summary. Have a look at the below example to see what it should consist of:
- Closed tasks & Sprint Goal:
During this Sprint, we have closed XX tasks.
The Sprint Goal was achieved/not achieved by closing those tasks/was not even defined.
- Unfinished tasks:
We are awaiting responses (from XX, YY, and ZZ) on XX tasks - they are staying in the current Sprint
There was not enough time to complete XX tasks (they were not crucial to obtain Sprint Goal)
XX tasks (became much bigger/changed scope), than initially expected - they will need to be split into XX tasks; there are still some clarifications pending
- Issues to address at Sprint Retrospective:
We agreed that we need to focus on 1X, 2X, and 3X to have better-quality Sprints.
Sailing Byte - an expert in Agile software development life cycle
Sprints are the best way to push your product development to the next level. Quick and effective, short and insightful. If well-planned, a good Sprint is a pleasure and a fantastic motivation for all Agile team members. But perhaps the most crucial part of every Sprint is that it gets the job done. Every well-conducted Sprint has a positive effect on the outcome of product development. Sailing Byte has conducted multiple Sprints and Sprint Reviews with every project. The success stories are proof of this process's effectiveness. Book a call today to discuss your ideas and find out how the sprints we conduct will get you your perfect product in no time.
