We have already discussed two different scenarios for when a work request comes into the Team. The second one described the situation in which the request arrives before the Refinement. But what happens if a request comes in after all the scheduled Refinements have taken place and we are nearing the end of the Sprint? There are even more possibilities.
Imagine that a Sprint Review is currently underway, and one of the Stakeholders has submitted a request to modify the product and the change has a high priority. Yes, the Sprint Review is the right place for Stakeholders to ask questions and request changes to the product, but we now have a new request that we need to handle soon and we're about to start the Sprint. If the Product Owner evaluates that this request has priority over others, they can use the Sprint Planning to refine it. If the time allotted for Refinement is sufficient and the requirement is ready for development, it can be included in the Sprint during Planning. This means that if several "ifs" are met, the Stakeholder can get the result of their requirement in only one Sprint.
However, more commonly, the Team will start processing the request at the next regular Refinement. Since we are at the end of the Sprint, the next Refinement will happen during the following Sprint. Ideally, the Team will be able to prepare the request during one or more Refinements in one Sprint. At the end of that Sprint or the beginning of the next Sprint, the Team will plan the development of the requirement. In order to keep it simple, we are talking about a requirement that can be developed within one Sprint and therefore, we need two Sprints to go from identifying the Stakeholder’s need to fulfilling it.
And what if the required functionality is too large to deliver in one Sprint? It depends on the Team. If they are experienced enough, they can split the required functionality by delivering the functional part – the increment – in each Sprint in which the development takes place. Taking the previous two cases into account, if we have a large requirement, the functionality that meets part of the Stakeholder's need will reach the Stakeholder in one or two Sprints.
But when will the Stakeholder get all the functionality that meets all their needs? Of course, if the requirement is complex, the answer is no longer simple. We are getting into the area of estimates. And how does the Stakeholder get this information? The Product Owner should be able to answer these questions. Therefore, the Stakeholder should reach out to the Product Owner to request the estimate.
In the examples above, I describe situations where I assume that the requirement has a considerable priority. But what about the opposite? When the priority is not high enough to justify a swift start of development? When will I, as a Stakeholder, get what I want?
The Product Owner is in charge of deciding the priority, how the Product Backlog will be sorted and what the plans are for the next period. They should know the answer to the question of when will I get what I asked for. Therefore, I repeat the recommendation from the previous paragraph: the Stakeholder and Product Owner should be in frequent contact with each other.
I mentioned Sprint Planning only in passing. In the next article, we'll take a look at how this event should be run.