I read several articles from different sources to try to find a recipe or guide on how to manage User Stories with set deadlines, and it seems that Agile development seems to address this issue by avoiding it. So basically, the recommendation is to not have User Stories with deadlines.
However, there are several situations that require assignments with strict deadlines. One of them is when there are legislative changes and the customer and the product they are using have to meet the requirements resulting from these changes. Another situation is when the customer needs a specific feature by a specific deadline either in order to gain a business advantage or due to other factors affecting their situation. In these cases, ignoring the deadline is not an option. So, let's dig deeper and see how we can address them within an Agile framework.
Let's imagine a situation in which we have prioritized and organized the Product Backlog (at this point, without deadlines). We assume that the items in the Product Backlog are estimated and the Team working on the product has a steady average Velocity. Then, we add a request with a definite delivery date. How will it affect our development strategy?
If the incoming request has the highest priority relative to other existing requests, it's simple: we rank it as the first item in the Product Backlog so that we can process it in the next Sprint. But things usually are not that simple. Let's look at a case in which our request has a lower priority. According to the Backlog item ordering rules, it should be placed further down in the Product Backlog.
Let's start from what we know. We know when the customer wants to have the required functionality ready, i.e. deployed on the production environment—the deadline. The request must be fully implemented in one of the Sprints preceding this deadline. Let's call it the implementation Sprint. Between now and the implementation Sprint, we have several additional Sprints (let's call them free Sprints) in which we can work on the other requirements that are at the beginning of the Product Backlog. We can use a simple equation to identify the position for the request:
Number of free Sprints x Team's average Velocity = sum of Storypoints of all User Stories that come before our request in the Product Backlog
Now we know how many other items can be worked on from the top of the Product Backlog before the request with the specified deadline. So, we place the deadlined User Story into the Product Backlog right after these, if not higher up.
And so, we have our request with a deadline now included in the Product Backlog. What if another request with a deadline comes in? The procedure is repeated, but now we check for two deadlines. With every additional request like this, we repeat the process and the number of checks increases—and with it, the complexity of maintaining the Product Backlog grows.
Now, our example here has pretty simple conditions; reality is different. The Product Backlog is a living dynamic list—new requirements are created, so the priority of existing requirements changes. Also, not every Sprint has the same speed. After each change, the Product Backlog needs to be rechecked and possibly rearranged. And the more deadlines that are in it, the more exhausting this activity becomes. At first glance, the principle is quite simple, but the whole situation is complex, requiring time, attention and patience.
In our next article, we'll talk more about the impact of User Stories with set deadlines.