When Will I Get It Then? (Part I)

In a previous article, the question was raised as to when I as a Stakeholder will get the functionality I want. The answer is simple, quick and my favourite: it depends. It depends on several aspects such as complexity, size and priority of the functionality. Sure, there are other factors, but I won't list them all.

To avoid getting lost in the complexities of the real world of Developers, let's set a few simple conditions to start with. We definitely want to work towards an answer.

Our requirement is represented by a single User Story, which is small enough that the Team can develop it in one Sprint. It is ready to be scheduled into the Sprint, meaning that the Team is familiar with it and has a plan or process and the technical means to implement it. Planning is underway or has just taken place, and the requirement has made it into the upcoming (just starting) Sprint. At the moment, we are just this one Sprint away from the expected outcome. At the end of it, the result of the implementation of our request will be presented to us, the Stakeholder. This will happen during a meeting called the Sprint Review.

Okay, but how long is one Sprint? Different teams may have different lengths set. The most common is two to four weeks. As a Stakeholder, I have the right to know this information by asking the Scrum Master of that Team or the Product Owner.

Where is the result of my request, and on what environment? Again, this can vary. If I am working with a Team that deploys the developed functionality continuously in each Sprint, then after the Sprint is over, the solution is fully available to me in the production environment. Otherwise, the solution is available in a test environment and the Product Owner knows within which Release and on which date the solution will be deployed on the production environment. Generally, it is the next Release after the Sprint is over.

I will allow myself a small interjection here. What does it mean that the solution is available or, in other words, ready? It must meet a set of conditions that each Team has defined. This is the well-known Definition of Done.

What happens if the requirement is more demanding and the Team is not able to deliver it in one Sprint? Then it is represented by multiple User Stories, which should be visibly linked from the Stakeholder's perspective. These User Stories are sequentially scheduled into two or more subsequent Sprints. So, I get the result of the solution in the Sprint in which the last of the User Stories, from which my request is composed, is completed.

What if I'm not satisfied with the delivered solution? In that case, when the solution is presented to me at the Sprint Review, I can comment on it and request changes and modifications. I can agree with the Product Owner and Team to implement additional requirements in the next Sprint. This process can be repeated several times until the solution to the requirement is good enough.

So when can I, as a Stakeholder, expect my request to be resolved if the Team receives it before the Sprint begins? Ideally in one Sprint, but again, only if the request is small enough for a Team to develop in that length of time.


In the next article, we'll talk about when the Sprint is in full swing, the Team is working on other tasks and our high-priority request comes in.

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…