Quid Pro Quo

In our previous article, we started talking about the rules in perfect development. And since there are many of them, we will devote a few more articles to them.

Here are the next few rules:

  • Developers can renegotiate the scope of the Sprint Commitment with the Product Owner as more is learned about the work, but a User Story can be removed from a Sprint only if the Product Owner agrees to have it removed.*
  • Quality goals do not decrease during the Sprint.
  • Only a Developer can add a User Story to a running Sprint.*
  • Developers can take new User Stories only from the top of the Product Backlog and only those that are Ready. If they need to skip a User Story, they must contact the Product Owner.*

 

Developers can renegotiate the scope of the Sprint Commitment with the Product Owner as more is learned about the work, but a User Story can be removed from a Sprint only if the Product Owner agrees to have it removed.*

During the Sprint, various new things may come up that significantly affect the delivery, and even though the Developers are doing everything they can to get the item done, they may discover that it is simply not possible. If this happens, Developers should contact the Product Owner as soon as possible. This information allows the Product Owner to notify the Stakeholders and give them the opportunity to think ahead about what the next Sprint will look like.

However, we know from experience that this is not typically how Developers handle the situation. Developers usually try their best to finish their given work, even if it is obvious that it won’t be finished within the Sprint. But finding a reasonable point at which a Developer says "Enough" is often quite difficult.

The possibility of removing a User Story from a Sprint is naturally linked to the fact that something is not finished in the Sprint. This decision is up to the Product Owner. The Product Owner can choose to leave the User Story in the Sprint to show that it didn't get done, even though the Developers promised it would.

This rule may sound a bit directive, but we are trying to avoid situations where it doesn't matter what and how much the Developers put into the Sprint. They may say, “If we don't make it, it just gets kicked out of the Sprint or moved to the next one. In the end, it doesn’t matter if we finish it or not,” but in actuality, it does matter.

 

Quality goals do not decrease during the Sprint.

This rule is directly related to the one above . Finishing work at the expense of its quality cannot be allowed. If that happens, we're generating technical debt that we will have to repay later, and usually with unpleasantly high interest.

 

Only a Developer can add a User Story to a running Sprint.*

Just like during Sprint Planning (more in this article), the same applies during Development: only Developers can pull User Stories into a Sprint.

 

Developers can take new User Stories only from the top of the Product Backlog and only those that are Ready. If they need to skip a User Story, they must contact the Product Owner.*

We have already discussed this point in one of our previous articles dedicated to Perfect Planning: Estimate and Select From the Top of the Product Backlog.

 

As I outlined in the introduction of this article, there are still more rules to come in two weeks.

Thank you for reading!