When Will I Get It Then? (Part II)

In our last article, we described a scenario in which a User Story is submitted right before Sprint Planning, is developable in one Sprint and is in a Ready state. We also mentioned that each team can have different Sprint lengths, and Backlog Refinements can also be set differently. So, the points at which a User Story reaches the Product Owner and they present it to the Team can vary significantly.

In this article, I'd like to describe when a Backlog Refinement is scheduled in the middle of the Sprint.

 

At the Refinement, the User Story is discussed with the Team and ideally marked as Ready. Unfortunately, just because we discuss something at the Backlog Refinement doesn't automatically mean it will be marked as Ready and that it will be taken into the next Sprint. We can, for example, find out that we are still missing information essential to understanding the assignment. In that case, we either call the relevant person to clarify the requirement within the Refinement or it is dealt with outside the Refinement and the User Story is discussed again at the next Refinement in two weeks. Usually, we are able to get the missing information quickly, allowing us to complete the Refinement in the current Sprint. Active communication with the Stakeholder is the key here. In addition, the Product Owner should be proactive because it is in their best interest to make the product deliver value.

When a Stakeholder submits their request to the Product Owner, they are naturally also interested in the delivery date. When the Product Owner says it will be a month at the earliest, there may be a moment of surprise. How is it possible that another team did it in two weeks but it's taking you a month? As mentioned at the beginning of this article, each Team may have their Refinement frequency set differently. They can prioritize differently and the length of their Sprints may be different. All these factors matter. In the case of refinements, the more frequently they happen, the more likely we will be able to clarify and get the User Story into the upcoming Sprint. So, if the Backlog Refinement happens once per Sprint and we get the User Story to a Ready status in the first Refinement, it is possible that it will go into the next Sprint. This would mean that it would be approximately three weeks from the time the request is submitted to the time the Team delivers it.

But we have to remember that a Product Owner is still responsible for prioritizing the User Story. It should be consistent with the overall logic of the Product Backlog. And thus, this doesn't mean that when someone asks for something, it goes right to the top of the Product Backlog. It's possible, but it shouldn't be the rule.

To avoid conflict around differing expectations of requirements delivery, it's important that Stakeholders are familiar with the Team’s process, including what happens at what time intervals and why, so that they too can arrange their work afterwards.

 

But what if the request reaches us between the Backlog Refinement and Sprint Planning? We’ll write about that in our next article.

You may also like:

Modes of Planning (Part I)

All the articles dedicated to the To Do List have been published. The last one was about the Developer’s To Do List. So, it is…

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…