What’s on the Agenda? (Part II)

In our previous article, we guided you through the first two points of the Planning Agenda. We described reviewing User Stories from the Product Backlog and clarifying where needed and committing to completing the selected User Stories in the Sprint through acceptance by initial Developers. This article will be dedicated to the next two Agenda points:

  • Break down User Stories into Tasks by the respective initial Developers.
  • Decide how to build the selected User Stories into a “Done” Product Increment during the Sprint.


Break down User Stories into Tasks by the respective initial Developers. 

During the Planning session, we take only those User Stories into the Sprint that are in the Ready state. (The Definition of Ready differs for different Teams and should be accessible to anyone in the company and anyone who cooperates with the Team. There will be more about the Definition of Ready in upcoming articles.) It means that User Stories have already been refined and estimated and that Developers know what the User Stories are about and know what needs to be done on their side and from a technical point of view.

Since one Developer can be assigned multiple User Stories in a single Sprint, it’s easy to forget the small details if they are only in the Developers’ heads. And yet, those details can have a big impact on the overall outcome. As a result, and because only high-level Tasks are created in the Planning session, it is good for Developers to record the smaller details in Tasks during implementation.

Developers can modify Tasks to reflect changes in approach and available information. They can create general “to dos” for themselves because Tasks solely belong to the Developers, and no one else can touch them – neither the Product Owner nor the Scrum Master.

It is good practice for Developers to break User Stories down into Tasks. It helps us either ensure that everybody understands the content of the User Story or, by breaking it down into Tasks, we discuss it and make sure we do not forget something important. The whole Team can see the implementation steps and determine if anything is missing or forgotten.

In addition, we avoid Developers taking too much into the Sprint. They can see how much they have taken already and can conceptualize the amount of work they need to deliver for each User Story. We do not use Tasks to track the Developers’ time, but we can generate a Burndown chart from the hours that Developers put into the Tasks. In this way, we can keep track of our progress from the very beginning, when we take the User Stories into the Sprint.

And at this point, we smoothly transition to the next Agenda point.


Decide how to build the selected User Stories into a “Done” Product Increment during the Sprint. 

The Definition of Done is always documented for each Scrum team. This document is created based on mutual agreement between the Developers and the Product Owner. Very simply, it is a definition of what it means when the User Story is considered to be “Done,” and everybody knows what that means. We will dedicate a separate article to the Definition of Done, so no worries, we will come back to it later.

So, how do you decide how to consider a User Story “Done”?

The key is to involve all the Developers in the discussion. They go over the selected User Stories and try to find possible solutions for how to process them. How to get them done. If they are missing information, they can invite other Stakeholders to the Planning event to clarify things or ask for technical advice.

When we talk about the Product Increment, we do not think about one User Story. The Product Increment is the comprehensive progress of all the User Stories completed during the Sprint towards the Sprint Goal. You may ask yourself, “What is the difference between the Sprint Goal and the Product Increment then?” The Sprint Goal is a vision of the end result. What we want to achieve during the Sprint. Where we want to get to. It provides us guidance in the right direction. The Product Increment is the result of the Sprint. It is the functional part of the whole system.

Developers should be able to explain to the Product Owner and the Scrum Master what strategy they will follow to accomplish the Product Increment by the end of the Planning event.


I hope we shed some more light on these two points from the Planning Agenda. Stay tuned for the last Agenda points in our next article.


Thank you for reading!

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…