Sprint planning

sprint planning
sprint planning

Sprint planning in sprint opening

Sprint Planning is the ceremony that the scrum team performs in sprint opening to frame the sprint that starts. Starting the development without preparing the work upstream, will make the sprint unstable; it is difficult to work without having a vision of the work to be done.

sprint in scrum
sprint in scrum

To work well with Sprint planning, it is essential to take the time. We speak about 2 to 4 hours for a 2 weeks sprint and 4 to 8 hours for a 4 weeks sprint.

It seems too long? It’s the time to plan well your sprint.

In sprint planning, we start with the current state of the backlog

Before even working on the sprint that starts, we have to start by making an inventory of the product advancement. It is essential that the entire team is clear on the progress of the product.

Doing a sprint schedule without knowing the status of the product can lead to the definition of bad goals.

In sprint planning, we define our objectives

So that the whole team to concentrate on what is expected at the end of the sprint, it is essential that the scrum team concretely define the sprint goal at the start of Sprint Planning.

The sprint goal is defined by a sentence understandable by all. For example: “We want to deliver a first version of the cart to users”.

The set of items (“user-story”, “technical task” …) don’t have the obligation to meet the objective of the sprint; however, the items that meet this objective have to be included. To explain simply, we must not define the objective of the sprint in relation to the items we want to develop; but, we will define the items that will meet the sprint goal.

The development team will be able to get the entire team to review the sprint goal if it considers during the sprint planning that it can not commit to deliver everything.

A goal is not a number series

If you understand this paragraph, you will easily understand that the sprint goal can not be: “we must deliver the JIRA25, JIRA26, JIRA27 …”.

The sprint goal have to be a sentence understandable by all; and the reason is rather simple. During a sprint, we can see that the sprint goal can not be achieved without a new user-story. So, the product owner will add a user-story (in agreement with the development team) during this sprint so that the goal will be achieved.

WARNING !!! It is quite possible to add items during a sprint. The scrum doesn’t prohibit this agile practice. In scrum, the sprint goal is fixed but the scope is variable. A sprint becomes obsolete only if its goal is no longer achievable.

Now, this user-story have to respect the “Definition of Ready”, if you use this practice, to see it in the “Todo”.

When the goal is defined, don’t hesitate to remind them throughout the Sprint Planning or even write them directly on the board. You can also let them display it throughout the sprint on their visual management.

Choice of items in sprint planning

When our goal is defined at the start of sprint planning, the scrum team will choose the items that will meet the sprint goal. All of these items should not exceed the capacity of the development team.

Only the development team have the right to comment about its capacity to do; and even if their opinion on this sprint goes against the indicators like the velocity. Velocity is just an indicator to help the product owner to have a vision and / or development team see the progress.

Items from the previous sprint

The development team is allowed to re-estimate the story point of each request in “working progress” of the previous sprint if they feel the need to better visualize their capacity to do; it’s not a mandatory to do that.

If you do this practice and the estimate is important to the team, here’s the trick I can give you. We will note the new story point of the request without erasing the previous story point written.

réestimer une complexité
reestimating the story point – sprint planning

For predictors, we keep the highest story point for calculating velocity (and for predictability) and the last story point awarded for the current sprint (to better determine the capacity to make of the team during the sprint and on the Burndown Chart).

In this example on the last picture, the team redefined the story point to 5 (8 during the previous sprint). We will consider 5 in story point for the team’s capacity to do and we will take off 5 on the Burndown Chart when the request is “Done”. On the other hand, we will put 8 in the sprint velocity in order to manage our predictability.

It is not mandatory that an unfinished item from the previous sprint comes back in this sprint; however, when an item is started, it can be disruptive for the development team not to continue to develop it in the new sprint.

Feel free to use the Poker Planning technique to do your estimates: Planning Poker: estimate your user stories

The complementary items?

If the development team thinks that they can still take additional items to those defined to meet the sprint goal, they will negotiate with the Product Owner to add new complementary items.

The reasons for the additions can be multiple to:

  • advance on other features with high added value
  • do analysis on tools that could improve the product
    rework on UX / UI aspects

Indeed, if the skills are focused on particular members of the development team, it’s possible to have members who will have a lower workload than other members. they will be able in sprint planning to purpose to work on other aspects with the aim of improving the product.

Can we re-estimate in sprint planning?

In general, the estimate is made in product backlog refinement (PBR); however, nothing prevents you to make estimates during the sprint planning. If the development team feels the need to better visualize their capacity to do, they can estimate:

  • new items not presented in PBR
  • items where the team thinks they have been wrong before
  • items from the previous sprint

However, we recommend that you don’t focus your activity on estimates (and predictability) because it quickly leads to many drifts.

Define the work to be done in sprint planning on the items

When the whole scope of the sprint is defined, the development team will have to cut each of the requests into technical sub-tasks. It’s possible that one request is represented by only one technical sub-task.

And to be more precise, the development team have to define all the work to do to deliver each item (as long as the team has enough elements to do it). If we often talk about front-back development tasks, it can also involve other aspects:

  • architectural aspects
  • UX works
  • UI aspects
  • possibly functional

Indeed, the sprint may include items that are not “ready” so functional work may be required. The development team will do this splitting work later when all the necessary elements are present.

WARNING !!! All sprint planning items are not necessarily “ready” during the sprint planning. If reaching the goal requires the addition of one item to work, this item must be added. The development team will know that it will have to be done when this item is considered ready.

Moreover, if the development team considers at this time that a research work will be necessary to achieve an item and that it can no longer commit to achieving the goal of the sprint defined above, the team and the product owner will together review the purpose of the sprint, or even the scope of it.

Example of technical division

There are no exact rules for this technical splitting; I advise the technical teams to make the cut with which it will feel as comfortable as possible.

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

  • HMI
  • Shopping cart API
  • Database cart
  • test
  • UI

The members of the development team have to do the most refined and simplest refined cut; give them the best chance of succeeding by not imposing the rules of splitting.

When all the work necessary to achieve at least the first items are defined, the sprint planning session is closed and the realization can begin.

Conclusion Sprint Planning

The Sprint Planning is the Scrum ceremony to start a sprint that can last up to 8 hours for a sprint of 4 weeks. It is often underestimated while it allows structuring the entire sprint. Indeed, by dispatching your sprint planning, you risk to have less stable sprints and experience some nasty surprises.

I hope this article will help you to do good Sprint Planning.

Another question about sprint planning? Don’t hesitate to ask your questions about the sprint planning in comment.

1 Trackback / Pingback

  1. Burndown Chart - Blog Myagile Partner

Leave a Reply

Your email address will not be published.