A deadline signifies more than just a point in time when work should be completed. It indicates that the project must be operational in a real-world production environment by that date without sacrificing quality. Simply regarding it as the moment to submit source code is shortsighted and ultimately dissatisfying for the client. And by deadline, I don't mean the classical scrum sprint deadlines.
These sprints, with their fixed timelines mostly based on literally nothing, often impose arbitrary deadlines that can lead to estimation overhead and short-term thinking.
Instead of adhering to traditional sprints with predetermined timelines for implementing a set number of features, our approach allows sprints to conclude once a collection of User Stories, also referred to as "Epics", are fully implemented. These sprints can span anywhere from two days, two weeks to several months or even longer. And since we prioritize deliverables over time. We do not try to squash a bunch of features to fit a golden number like "2 weeks". Each "sprint" is different. The asynchronous and parallel nature of task management allows to engage in multiple sprints simultaneously. For instance, if we have features A, B, C, and D to implement, rather than completing them sequentially, they all start simultaneously. If one feature, such as D, takes longer than expected, we don't halt progress, instead, we continue advancing. By the time we reach the midpoint of D, A, B, and C have already been completed. We use a ticket system to break down these larger features into smaller, independent, traceable, and billable tickets.
Estimating future progress is based on tracking the completion of these tickets over time, rather than predicting how much can be done within an arbitrarily defined classical "sprint" period. And by monitoring the rate of ticket completion, we can forecast project progress more accurately and adjust priorities accordingly.
This also reduces risk by minimizing the chances of encountering unforeseen complications in large and complex tasks. It allows for a steady flow of completed work. If an issue is particularly challenging, we can work on multiple tasks simultaneously without disruption. On top of that, code reviews become more manageable and efficient with smaller and laser focused units of work, which in turn enhances overall quality while reducing overhead.
In Case We Come Short
Additional time is always allocated for addressing unexpected challenges, but, when time is extra tight one must know where this extra time comes from:
- - Sacrifice code quality.
- - Outsource work or hire more engineers.
- - Drop low-priority features.
Sacrificing quality is a short-term fix, it will inevitably lead to issues later on. It's basically shooting yourself in the foot. Most software teams that opt for this approach end up with unmaintainable code, resulting in numerous bugs, performance issues, or even requiring a complete project rewrite. This is approach is never to be considered.
Outsourcing work is a viable solution, but it comes with additional costs. Therefore, it's only considered when it provides a positive EV
The latter option maximizes utility and minimizes losses the most, which in this case, is the optimal play. Before one drops features, they must already be:
Prioritized
Requirements are categorized using the MoSCoW method, where they're broken down into four priority levels: Must, Should, Could, and Won't, where Must-have features are non-negotiable, Should features are important but may be subject to evaluation, and Could features are considered based on time constraints. So dropping features is an simple two step process:
- - The feature's priority must not be classified as
Must. - - Client approval must be obtained before dropping the feature.
Once these criteria are met, the feature can be safely removed.
If the client still desires a dropped feature, it can be revisited after the deadline has been met and the product is operational. This additional feature could even serve as a supplementary marketing asset, further promoting the project's success.
Sometimes it may be realized that certain features were unnecessary altogether, this will allow resources to be reallocated to more critical tasks.