During the sprint, I work through the board from top to bottom. This means that the stories with the highest priority are addressed first. However, depending on the complexity of the story, it doesn't just stop at plain 'coding – testing – done.' The more dependencies there are, for example, to our own backend, to other microservices of our te am, or even to other teams, the more important it is to communicate. In my opinion, pair programming is almost always a good idea, regardless of the complexity of the task. Four eyes see better than two, especially when those two eyes have been reading the same three files all day. Alongside programming, code reviewing, and testing, continuing per sonal development should not be neglected. Even though I think that the best learning comes from working on tasks, it doesn't hurt to use free minutes and hours in the sprint to expand one's professional horizon through podcasts, articles, or workshops. After all, who knows what challenges the next sprint will bring?