Sprint Planning Meeting

What is Sprint Planning Meeting in Scrum? This is the opening ceremony of the sprint that is essential to  organize properly your sprints. We will see how to implement this sprint planning in Scrum.

You can watch the agile minute video on this topic :

Sprint planning in sprint opening

Sprint Planning meeting is the opening ceremony of Sprint before starting Sprint. There is little value in starting a Sprint without preparing it; it is difficult to work without having a vision of the work to be done.

In sprint planning, we define our objectives

It is essential that the Product Owner concretely define the sprint objectives at the beginning of Sprint Planning. The team will have a clear vision about the way to follow.

Although nothing imposes it, I advise you not to define the whole sprint as a goal to reach; this way of doing may regularly disappoint. If your goal contains 60% of the requests to develop during the sprint, you will have several significant positive effects:

• more chance to reach the goal (as it concerns 60%), so less frustration at the end of the sprint
• we prioritize in a certain way the content of the sprint
• we don’t risk putting pressure on the team.

I let you decide whether or not you want to apply this rule but I had a lot of positive effects applying it; I recommend you to do this practice.

When the objectives are defined, do not hesitate to remind them throughout the Sprint Planning or even write them directly on the board. You can also let them display throughout the sprint on your visual management.

In sprint planning, back in the future

Now that our goals are set, the team will have to re-estimate the story point of each items of the previous sprint that ended in “work in progress”; it is very likely that the story point of these items will not be the same because the team has already worked on them.

We will rate the new story point of the request without erasing the previous story point. Here is a way to do it on your posts:

For those that want to do predictibility, we keep the highest story point for calculating velocity (and for predictability) and the final story point assigned for the current sprint (to better determine the team’s capacity to the sprint and on the Burndown Chart).

In this example in picture, the team redefined the story point to 5 while it was 8 during the previous sprint. We will consider 5 in story point  for the team’s capacity  to do and we will remove 5 on the Burndown Chart when it will be Done. On the other hand, we will put 8 in the sprint velocity in order to manage well our predictability.

This work of re-estimation will be done on all the requests concerned before continuing. I remember that this work is useless on the requests that were already in “todo” during the previous sprint.

Feel free to use the Poker Planning practice to make your estimations during sprint planning.

The choice of requests to treat in sprint planning

The Product Owner will offer developers all the items they will have to develop during the sprint. These items will generally meet the objectives set at the beginning of the ceremony.

He will have to respect the capacity of the development team to avoid putting this team under pressure. This will materialize by limiting the number of items put in the sprint.

In general during the first three sprints of the team, developers are often asked to determine themselves what they are capable of doing during the sprint (explaining to them that the estimation error is really not serious).

We don’t estimate in Sprint Planning anymore

If we still estimated of Sprint Planning in the past, it has become rather rare to do so; it’s totally justified. Now we only do the re-estimations but never the new estimations.

We risked having to refine the items (mainly user-stories) in live because the PO had not necessarily thought of everything when he wrote them. He will also be forced to build his sprint backlog in live and perhaps to have to review his goals during the ceremony.

All these points multiplied the need for time-consuming and we could quickly end up with a ceremony of half a day; we add the tiredness and the loss of attention to stay hours in meetings and we ended up with a format not necessarily more productive.

Now, we do the Product Backlog Refinement to refine the user stories and to do the estimations.

By following one of these two concepts above, the PO will arrive in Sprint Planning with the objectives of the sprint and its content.

For the PO, instead of being left with an uncertainty of 40% on the content of the sprint, he will have 90% of the sprint defined.

Never say never

If the Product Owner urgently needs an exceptional estimation of a user-story from the backlog that is very simple but essential to process, the development team must not reject the estimation.

We are in agile projects so we must know how to adapt. We must not make the mistake of following everything to the letter if it’s bad for operation. And in this case, it will be not an issue for the team.

Splitting items into subtasks in sprint planning

When the whole sprint is defined, the technical team will have to split each of the items into technical sub-tasks. One item can be represented by only one technical sub-task.

Exact rules don’t exist for this technical splitting; I advise the technical teams to make the splitting as comfortable as possible for themself.

If we have as technical item: “refactoring of the front office”, we could have in sub-task:

• homepage
• cart
• product sheet
• cart api
• offer api

If we have as user-story: “As a customer, I want to add a product to the cart”, we could have:

• IHM
• cart API
• cart database

Your developers have to choose the most refined and simplest splitting for themself; it’s useless to impose them a kind of splitting.

When all items are splitted, the sprint planning session is closed and developments can begin; we then say that the sprint starts.

Conclusion Sprint Planning Meeting

Sprint Planning is the Scrum ceremony to start a sprint. I hope this article will help you put your Sprint Planning in place.

Useful link: scrum (in french)