5 consejos para una planificación eficaz del sprint

As we want to meet the objectives of the plan and ensure that no one has a bad time along the way, here we will present 5 qualities that every plan should meet to help ensure that it is not unnecessarily extended. 

Prioritized Sprint Backlog

It is essential to arrive at sprint planning with the backlog already prioritized. This work must be done beforehand so that during planning we can start directly with the most important user stories and tasks. If we want to have effective planning, it is unacceptable that in the middle of the meeting those involved face each other and say: “And now which ticket do we continue with?” 

User stories that meet the definition of ready

The Definition of Ready (DoR) is a set of characteristics that a user story must meet in order to be considered ready to be worked on. It is a kind of contract that the development team signs with the PO. What is included in it will depend on each project. It is vitally important that all tickets comply with the DoR in advance because this will ensure that there will be greater understanding when planning it and fewer unnecessary discussions. 

Some guidelines that a DoR could involve are: dependencies between identified user stories, attached designs or references, complete acceptance criteria, defined alternative paths, etc. If, for example, the user story being addressed in the planning does not have the alternative paths defined, that will undoubtedly trigger a series of questions by the development team, which, while essential and very useful, will drastically increase the duration of the ceremony. 

Collaborative

In addition to being good for day-to-day teamwork, it’s important for a sprint planning to be collaborative, meaning that all team members are aligned and collaborating. The Product Owner (PO) should be present during the meeting to clarify any questions about the user stories, and the team should have the opportunity to ask questions and offer feedback. 

All team members should feel comfortable sharing their opinions and there should be an atmosphere of collaboration and mutual respect. It might seem that this trust would lead to more discussions by increasing the duration of the planning, but on the contrary, what happens is that although there will be more dialogues, there will be less rework. 

If, for example, the PO of the project decides that he does not want to participate in the planning because everything is already complete based on his opinion, it could happen that the development team plans tasks that are not entirely correct or approached from a different angle and that it ends up being necessary to do another planning session, generating additional rework. Or worse still, he may realize this difference between expectation and reality after it has already been developed. 

Clear objectives

As with any ceremony, it is essential for all those involved to know what needs to be achieved and what is expected of each person in order to achieve their objectives in a timely manner. The work of the Scrum Master will be essential in this regard, to educate and be the moderator who ensures the integrity of the meeting. Only topics that concern the planning itself should be discussed; this is not the time to refine tickets. Obviously, I don’t mean that it is not possible to ask a specific question that can provide clarity on how to deal with a problem, but not to develop topics that are not strictly necessary for the current planning. Any other topic can and should be developed later.

Limited participants

To prevent the sprint planning meeting from becoming an endless meeting, it is important to limit the number of participants to the people who really need to be present. It is recommended that the Development Team, the Scrum Master, and the Product Owner be the only participants in the sprint planning meeting, unless someone else is needed to provide specific information. This will help reduce the number of unnecessary discussions and prevent the meeting from running too long.

Bonus track!

Even if you meet all these characteristics, do you think that planning is taking longer than desired? Some ideas that could be implemented depending on the project could be:

• Arriving at the planning stage with the tasking out in mind: If we have a user story that, by its nature, is going to be addressed by a particular person, that person could have the task list already thought out and estimated in advance. The goal is not to avoid conversations, which are essential, but rather the time to think about the initial guidelines. There are times when, at the end of the sprint, a participant has finished all the user stories and cannot help the team with the remaining ones. Why not, instead of taking on something new, dedicate the remaining hours of the day to gaining understanding about the tickets that will be developed in the next planning stage?
• Have a clear agenda: One suggestion might be to set a clear agenda for the meeting and make sure it is followed. This will help all participants know how the meeting is going to go and allow them to settle in so that they can get through it in the best possible way. Why not even set a break? Why not split it in two? You want to make it not a pain for the participants but something that everyone sees as useful.  

How do we know if we are on the right track? 

Planning is a very important ceremony and it is hoped that it will not be a nightmare for all participants while they seek to achieve their objectives. 

Following these ideas will surely improve the quality of the planning, but without a doubt the best indicator will be obtained by talking with the team during the retrospectives . It is essential to take advantage of this retrospective to identify how each person feels and what things can be improved so that the planning is more effective.