SPRINT PLANNING

If you ask 100 project managers what the biggest challenge they encounter in their work is, 76 will answer by talking about the obstacles they encounter when communicating with the team. Managing communication involves engaging your stakeholders, and it also involves maintaining the synergy of those involved. Good communication can be the difference between the success or failure of a project.

In predictive methods it was up to the project manager to identify what would be the milestones of the project, and what events the team should perform throughout the project to ensure a good development of the team. The agile methods shed more light on this interaction - the agile manifesto itself reinforces the idea of individuals and interactions more than processes and tools - and by placing at its base 5 major events, which form the pillars of interaction in scrum, they are:

1. Sprint Planning

2. Daily Stand Up Meeting

3. Sprint Review

4. Sprint Retrospect

5. Project Retrospect

Sprint Planning is the first of the scrum events, and is also used in other agile methodologies, its main function is to help the team understand the work that must be done, its effort, and more than that: a more assertive estimate of the tasks to be performed

The planning begins with the team choosing the stories they would like to work on in that period of time, following the prioritization order previously defined by the PO in the Backlog prioritization process. The stories have already been estimated, so we try to work always with the same amount of effort. It is the responsibility of the PO to define together with the team the sprint period, in order to meet the delivery schedule. When selecting the stories the team should also look if there are any dependencies between them, or other requirements that would delay their execution.

Having chosen the stories to work on, the team then starts to understand which tasks must be performed to execute each story. It is common that in a development team the team tries to understand the functional requirements (what the system must do), the non-functional requirements (how the system must be: secure, easy to use) and the business rules (e.g. Deploy on Tuesdays, authorize use only after federal identification of the user), in order to understand which tasks must be performed in its execution. In software engineering we often talk about functional and non-functional requirements, leaving the business rules out, but on a daily basis we realize that not considering the business rules can be a major obstacle for the project, and often results in rework.

Having identified the tasks the team then goes on to estimate the tasks to be performed, for this the team can either use estimation points again, with techniques such as poker planning, or they can use the Ideal Time, which is nothing more than the ideal time to perform a task if there wasn't any kind of interruption.

The last process in this ritual is the creation of the Sprint itself, this means identifying when each of the deliverables will be done, which roles should be played during the sprint, which stories will be worked on, and identifying the areas to be addressed by the project team. It is also interesting that the team has a clear goal established for that sprint, and that as much as possible the sprint is capable of delivering a Minimum Viable Product, in order to guarantee that the value of the project begins to be realized already in the first deliveries.