It Should Matter to Everybody

In our previous article, we wrote about the fact that only Developers can add User Stories to Sprints. One of the issues we will describe in this article is: what if someone on the Team has trouble finishing the work planned for the Sprint?

Three rules around this are:

  • User Stories accepted into the Sprint by Developers after its start must be refined by the whole Scrum Team and meet the Definition of Ready*
  • Developers should release an assigned User Story to another Developer if they see that they cannot efficiently develop that User Story in the Sprint.*
  • Developers should release an assigned Task to another Developer if they see that they cannot efficiently develop that Task in the Sprint.*

 

User Stories accepted into the Sprint by Developers after its start must be refined by the whole Scrum Team and meet the Definition of Ready criteria.*

You may have noticed one small detail in this rule: refining by the whole team. You might think that only those who have a real say—in other words, those who will work on the User Story—should do the refinement. But let's not forget that ultimately, the whole team is responsible for the delivery, not one single Developer. And besides, you never know if someone knows something additional that can influence the development and the overall picture. Therefore, if you want to refine work properly, you should do it with the whole team.

But why can User Stories be accepted into the Sprint after its start?

Let's imagine that someone submits a new feature (not a bug) that needs to be done in the current Sprint. In this case, there may be different alternatives. If the inclusion of such a User Story in a Sprint jeopardizes the Sprint Goal, the question is whether to cancel the whole Sprint. If not, we can refine the User Story and think about a possible "piece for piece" exchange of the User Story or another appropriate amount of work. Such an exception is possible, but it should not happen on a regular basis. Plus, this decision rests with the Developers, as they are the ones who own the Sprint Backlog.

 

Developers should release an assigned User Story to another Developer if they see that they cannot efficiently develop that User Story in the Sprint.*

Right from the start, we can say that it is unlikely that someone has extra capacity to help a Developer who is not keeping up. This is because everyone plans to the best of their knowledge and ability to have as much work to do during the Sprint as they can realistically manage.

If this situation arises, it is certainly advisable for the Developers to speak up, and to do so during the next Scrum event, which is usually the Daily Scrum. Daily Scrums are actually designed to provide an opportunity to raise issues such as this. At that time, you can come up with a plan for how to deal with the situation. And if you discover that the User Story cannot be finished, the Product Owner needs to know about it and inform the stakeholders.

 

Developers should release an assigned Task to another Developer if they see that they cannot efficiently develop that Task in the Sprint.*

In principle, this is the same as the last point. The key is that the one who is responsible for completing a given task from the beginning should be the one who also ensures that someone else takes it. We are trying to make sure that someone doesn’t just "drop" a task and that’s it.

 

With this article, we completed the second half of the rules in Perfect Development. In two weeks, we will return with another series.

Thank you for reading!

You may also like:

What Should Happen During Planning

In our last article, we finished talking about User Stories with set deadlines. In this article, we would like to summarize the Planning to explain…

Should a Scrum Master have a technical background and skills?

That is a very good question, I guess. Or at least, you can find a lot of articles about it with various points of view.