Let Them Work

The development cycle is the time dedicated to the most important thing about the Product: its creation. To ensure that this is not the work of chance, it is advisable to follow a few basic rules that will help us not get lost.

There are more rules than fingers on one hand, so we will describe them in a few articles. We will start with the following:

  • The created Product Increment must be usable so that the Product Owner may choose to immediately release it. If it is not usable, it is not Done.
  • The Product Owner is not allowed to request additional Sprint Backlog changes from the Developers during the development work, nor is the Product Owner allowed to initiate direct contact with any Developer.*
  • The Product Owner can freely contact the Scrum Master.
  • The Product Owner can cancel the Sprint if the Sprint Goal or development work become obsolete.
  • Developers can freely ask the Product Owner to further clarify User Stories.

 

The created Product Increment must be usable so that the Product Owner may choose to immediately release it. If it is not usable, it is not Done.

What does it mean that the Product Increment is usable? The individual User Stories that make it up must be complete and together; they must form a functional part of the system. At the same time, the Product Increment is ready for release and does not require any further work. So, it is up to the Product Owner to "only" choose the release date. Otherwise, we cannot say that the Product Increment is Done.

 

The Product Owner is not allowed to request additional Sprint Backlog changes from the Developers during the development work, nor is the Product Owner allowed to initiate direct contact with any Developer.*

The Sprint Backlog is composed of User Stories that fulfill an agreed strategy leading to the Sprint Goal. If someone interferes with the Sprint Backlog during the development cycle, they will disrupt this strategy and may cause the Sprint Goal to not be met. Therefore, even the Product Owner cannot request such changes…with one exception: the Product Owner can cancel the Sprint. This is covered by another rule.

Working on a Product Increment is often challenging and requires focus. Any interruption usually has a negative impact on delivery. If the conditions for development are to be as good as possible, even the Product Owner is not allowed to contact anyone from the development Team during the development cycle. However, there may be situations where the Product Owner needs to start communicating with the Team, but this is covered by the next rule.

 

The Product Owner can freely contact the Scrum Master.

When Developers commit to a Sprint Goal, the Product Owner trusts them and therefore does not need to contact them during the development cycle. They wait until delivery. However, if there is an unforeseen serious situation that they cannot handle, they can contact the Scrum Master at any time so that they can search for viable solutions together.

 

The Product Owner can cancel the Sprint if the Sprint Goal or development work become obsolete.

The environment in which we operate is so volatile that from time to time there is a situation in which the Product Increment that the Developers are working on ceases to have the desired value. At that point, the Product Owner should exercise their veto power and cancel the ongoing Sprint. By abandoning the original plan, the time remaining in the Sprint is saved and can be used for more relevant work.

On the other hand, if there are frequent Sprint cancellations, we need to identify the causes and adjust the process to reduce the amount of unfinished work. Sometimes we just need to adjust the length of the Sprints. Other times, a deeper analysis and bigger changes are required, perhaps even within the Team itself.

 

Developers can freely ask the Product Owner to further clarify User Stories.

During development, as the work progresses, there will be places in the specification or the Product itself that need to be clarified for further progress. That is why Developers can freely contact the Product Owner.

 

Meaningful things also need to be done, which is why we'll cover the next part of the rules in two weeks.

You may also like:

AMI Interview with Jan Pisarovsky - Working from home during the lockdown

In this edition of AMI interview, we virtually sat down to talk with Scrum Master Jan Pisarovsky about the struggles one might face when…

Five Tips for Working from Home

Some of you were probably hoping for a zombie apocalypse as I was. And all we got was this lousy coronavirus. Jokes aside, the current…