In our previous article, we brought up the topic of User Stories that have a set deadline and how to deal with them. Whether User Stories with deadlines are common or not, it is important to think about the impact that such User Stories can have.
When we talk about impact, we can talk about both positives and negatives. But let's face it, the chance of User Stories with deadlines having a positive impact on the Product Backlog, the Team or Sprint itself is not very high.
In this article, we will talk specifically about two examples of requests with such tight deadlines that the Product Owner has to put them either at the very beginning of the Product Backlog or into an already running Sprint.
Imagine that you order the Product Backlog by, for example, what will be done first, second, third and so on, taking into account what will bring you the most value. With the Product Backlog sorted in this way, you are ready to start the next Sprint. The Team, the Stakeholders, they all know what the plan is for the next Sprint; they know what's coming. And then suddenly, you receive a User Story that has a very short deadline. What happens next? The Product Backlog changes. The order of development of each thing in the Backlog changes. You say to yourself, “this can't hurt anything”. This is Agile after all, isn't it? Yes and no. There is a catch. It all depends on how often these changes happen.
If you deal with a User Story like this once, nothing will probably happen. But if these User Stories start dropping into the Product Backlog more and more frequently, it's only a matter of time before the Product Backlog becomes a set of randomly arriving requests that are all on fire.
In another scenario, suppose we tell the Stakeholders that we will deliver a particular item within a two-month timeframe. If User Stories with short deadlines start falling into our Backlog, we won’t be able to deliver that particular User Story that was supposed to be ready in two months. Now it will probably take three months. It will shift. And let's view it from the other side. You're the Stakeholder of the team. You're counting on something and you're going to arrange things accordingly. And all of a sudden, it all shifts. Once, no big deal. But if it happens often, you'll stop listening to how the Product Owner of that team told you they planned to deliver. Quite simply, you'll lose trust in the team.
The next situation is if the deadline forces the team to put the request into an already running Sprint. How will User Stories with short deadlines affect the progress and outcome of a Sprint? Let's start at the beginning. When we plan a Sprint, Developers are the ones who pull things into it. They scoop up as much as they think they're capable of delivering at the end of the Sprint. Let's imagine a situation where on the second day of the Sprint, a Product Owner needs to put another item into the Sprint due to an early deadline, and they know that unless they start working on that item in the current Sprint, it cannot be delivered by the deadline.
If we add the item to the Sprint, we run the risk that the items the Development Team committed to delivering will not be delivered in the end because they will have to turn their focus elsewhere. The Sprint goal can also be compromised and with it, the whole point of the Sprint can be lost.
The implications I've outlined in the article may seem exaggerated, but they happen more often than you think. It is therefore better to be careful and pay extra attention when dealing with User Stories that have deadlines.
In our next article, we'll start to cover why and how the time when the Product Owner receives the request determines the final delivery. You’ll read about it in the next few articles.
Thank you for reading!