Nexus Sprint Planning

Nexus is a simple framework which implements scrum at scale across multiple teams to deliver a single integrated product. It can be applied to 3-9 scrum teams which are focused on producing a combined increment in every sprint.

Sprint Planning in Nexus

The sprint planning session has two parts.

In the first part, the Nexus Team conducts a sprint planning session in which they plan the bigger picture of the project. Information and decisions made based are conveyed to the scrum teams. Dependencies are found and sought out. The backlog can have stories, tasks, business initiatives, epics or any item of any size that suits the teams.

For the second part, scrum teams have their individual sprint backlog to work on. During these sprint planning session, teams interact and collaborate with each other. Teams align themselves in order to achieve their sprint goals. At the completion of all teams sprint backlog planning, Nexus Sprint Backlog is ready.

The Nexus Team and the Scrum Teams work in cadence. The teams pick out items from the refined Nexus Product Backlog.

Items in the product backlog are continually refined to minimize or clear away dependencies. New requirements can also be added. It also includes carrying out relevant estimates of story points.

The product owner has the Nexus Product Backlog but if the size of the teams exceeds, then the product owner may delegate some of their tasks to the scrum teams, business analysts, project managers or other roles.

How does this Planning compare to that of Scrum?

In sprint planning you plan what needs to be delivered in the upcoming sprint and how will work be done to achieve it to deliver in the sprint.

When it comes to planning a sprint in Scrum, here are the key events that happen:

  • After the review and retrospective of the previous Sprint, the Sprint Planning session is held.
  • It is usually kept in a place where all the teams are present. It is set at a time at which everyone can easily manage to attend.
  • The Product owner discusses to the development teams, what needs to be made in the product increment along with the scope and the Sprint Goal. They have to explain to the team what needs to be done or clarify on any detail of the product backlog.
  • The backlog is prioritized which consists of the items which need to be worked on in order to achieve the sprint goal.
  • The backlog is kept accessible and transparent to all.
  • All blockers and dependencies are identified.
  • The Scrum Master acts as an intermediary between the team and the product owner and clears up any problems that they the teams may have may face in understanding the requirements.
  • Using the metrics from the previous Sprint such as velocities and capabilities, the outcome of the sprint is forecasted and to see how confident the teams are in completing their tasks.
  • Once the sprint goal is decided and the items from the backlog are selected, the development team figures out how they will achieve their tasks to get their definition of done.
  • The team has to agree to all the items of the backlog.
  • Now the development teams create a strategy and mind map with how to achieve their sprint goal. Ideas are discussed on to how to deliver.
  • They pick out items from the product backlog which they think will help fulfill their sprint goal. The list of items selected from the product backlog that needs to be worked on in the sprint, form the Sprint Backlog.
  • Seeing the items in the sprint backlog, the development teams adjust themselves according to that. They self-manage themselves in a way that they know they can really achieve what they are aiming for.

About Kendis

Digital boards to manage dependencies, multiple teams and program increments for scaling agile initiatives. Kendis works on top of JIRA and other agile tools, your teams can keep on working with their existing JIRA boards and program level and above is planned and managed at Kendis.
Try out 30 days free trial or book a demo with our product expert.