Scaled Professional Scrum and Nexus – Nexus Sprint Planning

Nexus Sprint Planning is the scaled version of the Sprint Planning event from the Scrum Framework.

How does it work?

The Nexus Sprint planning event is used to plan, coordinate and align the work to be done by the Scrum Teams in the current Sprint. It is another opportunity to identify and eliminate or reduce dependencies between Product Backlog Items so Scrum Teams can plan and work on them independently.

To begin the event, appropriate representatives from each Scrum Team will validate and make adjustments to the ordering of the Product Backlog Items, building on what has already been completed in Product Backlog Refinement events. The ordering will help reduce dependencies between Scrum Teams in the Nexus during the Sprint.

Product Backlog Items will be then be selected by an appropriate Scrum Team that has the skills required to deliver them with no (or minimal) dependencies on other Scrum Teams. The Scrum Team should have all the cross functional skills required to translate the Product Backlog Item into an integrated Increment by the end of the Sprint.

The Nexus Sprint Goal will be formulated in Nexus Sprint Planning. It will describe the purpose that will be achieved by the Nexus during the Sprint.

Once the teams have selected their Product Backlog Items, they will carry out their own separate Sprint Planning to plan their own work in greater detail. As new dependencies are discovered they will be shared, visualised and minimised via the Product Backlog.

The Nexus Sprint Backlog will be created during Nexus Sprint Planning. This will be a combination of the Sprint Backlogs created by individual Scrum Teams and will additionally highlight cross team dependencies.

Who should attend?

Nexus Sprint Planning should be attended by all Scrum Teams and include all team members.

In reality it can be tough to coordinate this large number of people, so each Scrum Teams should nominate a smaller number of appropriate people to represent the team when planning discussions are carried out at the Nexus level.

Once individual Scrum Teams take their Product Backlog Items for Sprint Planning at the team level, all members of each Development team should take part as they would using Scrum.

The Product Owner will provide domain knowledge to clarify Product Backlog Items and will guide priority and selection decisions. This event may place excessive demands on the Product Owners time so may be an instance where they will need to have specialist assistance to represent them at the individual Scrum Teams level.

A Scrum Master will be needed to facilitate this event. With the number of people and teams involved, the facilitation skills of the Scrum Master will be vital to ensure the event is carried out effectively and can be completed within a reasonable time box without confusion and conflict.

What is the time box?

The Nexus framework suggests that the duration of Nexus events be guided by the length of the corresponding events in the Scrum framework. So for Nexus Sprint Planning the target for the time box would be 8 hours for a 1 month Sprint.

Inspection and adaption may lead to this being adjusted over time as required. Depending on the number and location of teams in the Nexus and the level of dependencies being handled, the time required may vary significantly between Nexuses.

When and where does it take place?

Nexus Sprint Planning should be held at a consistent time and place to ensure attendees have a clear expectation of when and where they need to be in order to take part.

Where possible, Nexus Sprint Planning will be held in a large space that allows all Scrum teams to come together and work in close proximity. This will allow the teams to communicate and share learnings during the event which will make it more effective.

What else do I need to know?

Having a Product Backlog refined to “Ready” with dependencies reduced/eliminated and an indication of which Scrum Team will deliver each Product Backlog Item is likely to be an essential prerequisite to allow planning to proceed effectively.

Strong facilitation of Nexus Sprint Planning by a skilled Scrum Master will be vital to making this event constructive and allow its objectives to be met.

Planning at Scale using large numbers of teams and people can be a significant challenge. Scaled Professional Scrum introduces a number of additional practices to help make this effective.

Next post: Nexus Daily Scrum –>

<– Previous post: Product Backlog Refinement

Index – Scaled Professional Scrum And Nexus – The Definitive Guide


The Scrum Master is Simon Kneafsey. Simon is a Professional Scrum Trainer with, the home of Scrum run by Scrum co-creator, Ken Schwaber. Simon offers Professional Scrum Certification training courses globally and works with clients to introduce Scrum to their organisations.

Share this Post

Comments 14

  1. Simon thanks for an Excellent explanation. Some of my doubts are cleared after reading this blog. Again thanks for all your work on proliferating SPS & Nexus. Waiting for remaining blogs of this series to complete before I go for SPS.

    1. mm Post
  2. Hi Simon,

    If multiple Scrum teams are working on the same Product (similar to Nexus), the Sprint length for all the Scrum teams should be same or they can have different sprint length?

    As per my understanding Sprint length for all Scrum teams should be same, else synchronization issue will arise in producing the Integrated Increment.

    Kindly clarify.

    1. mm

      General rule is Sprints should have a common end date, but can be different lengths for teams in the Nexus.

      E.g. 1 Scrum Team could have 1 week Sprints while others have 4 weeks Sprints as there would be a common end date at least once every 4 Sprints and this is when The Nexus Sprint Review would be held. Following on from this it wouldn’t usually work for 1 team to have 3 weeks Sprints whilst others in the Nexus have 4 week Sprints as there would be no common end date.

      Even with this simple explanation there are exceptions possible, perhaps where continuous integration is in place and being utilised successfully. Have a read of this interesting post:

      1. Hi Simon,
        Isn’t equals sentences “Sprints should have a common end date” and “Sprints should have a common start date”?
        Let’s imagine 2 teams, we have posible folowing combination Sprint length: 4W+2W, 4W+1W, 3W+1W, 2W+1W
        It looks like correct statement too. Or it is something connected with Nexus Guide and Nexus Review event (it replace Scrum review)?

        1. mm Post

          Hi Marcin,

          I am not sure I understand your question.

          The Sprint length options you list are valid.

          The key point is that at Nexus level, there must be a common Sprint end date for all teams. Some teams may complete more than one Sprint by this point.



  3. Hi Simon,

    In fact I have a question regarding the Nexus guide itself in part of the Nexus planning meeting and how it appears in the test and if it’s appears.

    The text in full is as follows:

    “To begin Nexus Sprint Planning, appropriate representatives from each Scrum Team validate
    and make adjustments to the ordering of the work as created during Refinement events. All
    members of the Scrum Teams should participate to minimize communication issues. ”

    It was confusing for me because in the beginning of the paragraph is written representatives and is then placed all members should participate.

    On your website at the beginning of the Nexus Sprint Planning all members of all teams must participate, but then put that in the beginning only representatives will and so the backlog of each team is set is that everyone participates.

    This meeting is divided into two parts, what and how like scrum guide? The first part involved the appropriate representatives and the second all participate?

    Thank you!

    1. mm Post

      Hi Mathias,

      Thank you for the feedback. I agree this point can be a little confusing and tough to explain. Think of Nexus Sprint Planning as a wrapper and addition to standard Sprint Planning. We want to involve all those that want/need to have input to identify dependencies and cross team issues, primarily in the first part of Nexus Sprint Planning, but also throughout as issues are discovered. However doing this at scale comes with some practical problems.

      All team members should have the opportunity to participate and contribute at Nexus level. Typically appropriate representatives will take the lead at communicating issues/dependencies to Nexus level. This is because Nexus Sprint planning may involve many people (e.g. 9 Scrum Teams of 9 people each – 81 people) so you will need tactics to facilitate the inputs from this number of people. Having appropriate representatives communicate issues from each team to Nexus level is a good mechanism to do this. Other ways are of course possible.

      Once the Scrum Teams start to plan their own work for the Sprint in their Sprint Planning events all team members would be fully involved as usual.

      BTW – Scrum no longer differentiates between 2 parts of the Sprint Planning event. Both the What and How topics need to be discussed and planned, but you do not need to carry these out separately. There will typically be some back and forth between the topics and this is fine.

      I hope that helps clarify things for you.


  4. Hi Simon,

    I have some concerns here:
    1. Which day in Sprint that the Nexus Sprint Planning will be happened? At day 1 or any other days in previous Sprint?

    2. Nexus Sprint Planning must be done before the Sprint Planning of each Scrum team, is it correct?

    3. Also the Nexus Sprint Goals should be finalized for other Sprint Goals of each team to align with.

    Thanks for your sharing! Your website is very helpful for us.


    1. mm Post

      Hi Minh,

      Thank you for the kind words.

      Some interesting questions. Here is what I think:

      1) Nexus Sprint Planning should happen as early as possible in the Sprint. Day 1 in most cases. However, this may not always be possible. For example, if the teams are distributed and in different and far apart time zones.
      2) Sprint Planning for each team is part of Nexus Sprint Planning.
      3) Nexus Sprint Goal and Sprint Goals will be set as part of Nexus Sprint Planning.

      I hope that helps.



      1. Thanks Simon for your quick responses! It is more clear for me now.

        One more thing, I would like to ask for your consultancy in a rare case that each Scrum team has different Sprint length (ex: 4W and 1W), so the Nexus Sprint Planning will only happen per 4 weeks, is it correct?

        And other Sprint Plannings of the “1W Sprint ” teams are also apart of the Nexus Sprint Planning, so the Nexus Sprint Planning will only finish after the 4th Sprint Planning of “1W Sprint” teams is done.

        Also, we will need to prepare enough Backlog items for the “1W team” to work on 4 Sprints.

        Many thanks for your advice!


        1. mm Post

          Hi Minh,

          In your scenario Nexus Sprint planning would happen once at the beginning of the 4 week Sprint. It would still finish early in the Sprint (Day 1 perhaps). The team doing 1 week Sprints may need to plan enough (and perhaps somewhat in advance) work to be able to align with the rest of the Nexus. They could plan in more detail as part of their weekly Sprint Planning cycle.



          1. Thanks a lot, Simon! I am clear now.

            From my point of view, it will be better if we have the same Sprint Length for all Scrum teams to make thing run smoothly and synchronously.


          2. mm Post

Leave a Reply

Your email address will not be published. Required fields are marked *