A Developer’s To Do List

Ok, the Product Owner’s To Do List and Scrum Master’s To Do List are done, so the last one left is the To Do List for Developers.

What does it include? Let’s have a look:

  • Cooperate with the Product Owner and Scrum Master on User Stories review and clarification.
  • Select User Stories for the next Sprint from the Product Backlog and commit to their completion.
  • Break down your assigned User Stories into Tasks.
  • Estimate your Tasks.
  • Help set up the Sprint Goal.
  • Help refine the User Stories if needed.

As you can see, some of the points may be familiar to you from previous articles, so I will give links to refresh your memory and elaborate on just the parts specific to Developers.

 

Cooperate with the Product Owner and Scrum Master on User Stories review and clarification.

 As mentioned before, it is up to everybody in the team to make sure that they understand what the User Story is about. If something is not clear to the Developers, such as what the final functionality should be, it is up to them to ask about it and get clarification.

 

Select User Stories for the next Sprint from the Product Backlog and commit to their completion. 

Developers are taking User Stories into the Sprint from the Product Backlog as they are sorted from top to bottom, one after another—as long as they think they have the capacity to deliver the User Story within the Sprint.

Because Developers have the right to take to the Sprint only the amount of work that they are able to deliver, no one should push them to take more than what their capacity allows. By taking a User Story into the Sprint, they are committing to deliver the User Story within the Sprint. This commitment does not mean that they will deliver the User Story within the Sprint no matter what, because sometimes during User Story processing, the Developers can discover something that nobody knew or expected. Rather, the commitment means that they will do everything in their power to deliver the User Story within the Sprint.

 

Break down your assigned User Stories into Tasks. 

This topic was covered in this article in full.

 

Estimate your Tasks. 

Tasks are estimated using hours. This information is solely to help Developers realize how much work has to be done on the current User Story and whether they correctly estimated its complexity. Each Developer only estimates their own Tasks. Estimation of Tasks can spark further discussions to better understand User Story implementation. It also enables the Developers to sort and prioritize their work.

The hours assigned to Tasks are used to create the Burndown chart that helps better orient the team regarding the progress in the Sprint. Based on this, they can see how much work is left within the Sprint Backlog, how fast they are processing the work and, if they manage to deliver everything, how much of the Sprint it took.

 

Help set up the Sprint Goal. 

The Sprint Goal should be clear at the start of the Planning session, but sometimes, based on the User Stories taken into the Sprint and the expected result of the Sprint, it may need to be adjusted. If Developers notice a discrepancy, they must help to set up the Sprint Goal correctly.

Read more about setting up the Sprint Goal in this article.

 

Help refine the User Stories if needed. 

Developers need to cooperate with the Product Owner to make sure it is clear what they need to deliver. Then, it is up to the Developers to decide how to deliver it and what the technical requirements are for delivering the User Story. Read more about refining User Stories here.

 

And with that, we finished the To Do Lists for each member of the team. Our next topic will be the planning modes of the Sprint.

 

Thank you for reading,

Have courage and be kind

You may also like:

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…

A Product Owner’s To Do List

Lately, we have been writing about the Planning Agenda a lot. Now it is time to explain the To Do list for the roles we…

Comments