What’s on the Agenda? (Part I)

We explained what Planning in ScrumOne is in a previous article. We also mentioned that is has an agenda.

Every meeting has different rules and there are different things that need to happen in it. The agenda for Planning is:

  • Review User Stories from the Product Backlog and clarify where needed.
  • Commit to completing the selected User Stories in the Sprint through acceptance by initial Developers.
  • Break down User Stories into Tasks by the respective initial Developers.
  • Decide how to build selected User Stories into a “Done” Product Increment during the Sprint.
  • Set up the Sprint Goal (a simple sentence used by the Product Owner to inform Stakeholders of the goal of the upcoming Sprint).
  • Refine User Stories in the Product Backlog if needed.

Each item has its reason for being included in the agenda. In this article, we are going to talk about the first two.


Review User Stories from the Product Backlog and clarify where needed. 

User Stories are added to the Sprint from the Product Backlog, where they are ordered top-down by the Product Owner by priority, business value, strategy and risk. User Stories fulfill specific criteria that determine when they can be taken into the Sprint. That means that the team has already seen the User Story and they know what it contains, how to develop it, how big it is and how to present it to the stakeholders/customers.

Nevertheless, in the time between the Refinement of the User Story, when the team clarifies the User Story, and when the Planning can happen, the scope of the User Story will change. So, we need to make sure that we capture and reflect any changes to the User Story while taking it into the Sprint.

Also, not every User Story from each Sprint is finished within the current Sprint. This can be for various reasons: for example, we do not know exactly how many things we are able to develop during the Sprint, or we can encounter some obstacles during development and the solution will take more time than we thought, so we will not be able to finish it during the current Sprint. Or, we take a User Story into the Sprint after the Planning, but before finishing all the ones that are already there, so we do not manage to finish everything. I am sure that you can think of more reasons why we do not manage to deliver every single User Story that was taken into the Sprint.

So, the User Story that has not been finished within the current Sprint and has to be completed within another one has to go back to the Backlog, where it gets prioritized among the others by the Product Owner. Organizing the Product Backlog is continuous work, as priorities can change during development. This means that even the User Story we were working on in the last Sprint that is not finished could have a lower priority than the User Story that is waiting in the Product Backlog to be taken into the Sprint. That is why an unfinished User Story has to go back into the Backlog and be reviewed by the Product Owner.

It is true that an unfinished User Story often goes right into the next Sprint, but it still has to be revisited by the team. They need to see how much work is left, if there are potential changes and how much capacity the finishing of the User Story will take.


Commit to completing the selected User Stories in the Sprint through acceptance by initial Developers. 

Within the Scrum, there is nobody besides the Developer that can agree on developing an individual User Story within the current Sprint. That gives them the freedom to take into the Sprint only the amount of work they think they can manage within the Sprint. But this also means a responsibility for each User Story and its delivery. It is also true that the final result of the Sprint is not the responsibility of the individual Developer, but of the whole team. So, if the initial Developer that committed to delivering the User Story has a problem with delivering the work, the other team members should actively help him finish it. That applies to all member of the dev team, regardless of their role – back-end, front-end, QA, UX, etc.

For example, if QA does not have enough time to test all the User Stories, developers can help test them. If one developer has already finished his work and a User Story remains within the Sprint Backlog, he should offer his capacity to help finish it.


Does this make sense? More complex that you thought, right? And this is just the start; we will continue going through the agenda in the next article.


Thank you for reading, have courage and be kind.

You may also like:

Modes of Planning (Part I)

All the articles dedicated to the To Do List have been published. The last one was about the Developer’s To Do List. So, it is…

A Scrum Master’s To Do List (Part II)

Ok, you already read about the To Do list for Scrum Masters, so why are we mentioning it again? Since the Scrum Master’s To Do…

A Scrum Master’s To Do List (Part I)

Our previous article in our Perfect Planning series was dedicated to the Product Owner’s To Do list. If you take a look at the ScrumOne…