Can Scrum Work for Hard Deadlines?

If you’ve ever wondered whether Scrum can work for hard deadlines, the answer is – yes! Not only can Scrum work in these situations, but in my experience, using this agile framework increases the probability of meeting challenging deadlines.

Scrum works well with deadlines because it’s based on empiricism, lean thinking, and an iterative approach to product delivery. In a nutshell, empiricism is making decisions based on what is known. Lean thinking means eliminating waste to focus only on the essentials, and iterative delivery involves delivering usable product frequently.

Let me demonstrate these concepts with a story.

Once upon a time, there was a Scrum Team consisting of seven Developers, one Product Owner and one Scrum Master. This team faced a significant challenge. To meet business needs, it would need to rewrite substantial portions of the technology product within six months. If the work was not completed by a specific date, the business would face significant organizational losses worth many times the annual budget of the Scrum Team.

Empiricism

Empiricism asserts that one should make decisions based on what is observed or known. To determine whether the team could meet its goal, it created Product Backlog items, or to-do items, representing what was known about the work and then used the complementary practice of points estimation. Rather than estimating their work in hours, the team used relative sizing to assign points to each of the Product Backlog items using a previously agreed upon measurement system. The system allowed the team to estimate the total points of work required to deliver the new business requirements.

Next, the team took the total points and compared that to their current velocity. Velocity is the total number of points that the team has been able to deliver or complete, every previous Sprint (iteration). Using this information, the team could calculate how much time it needed to deliver the new business requirements.

The result? Based on their analysis, the team determined that they would not be able to deliver the requested work within the timeframe requested.

Next, the team performed an analysis to determine how many additional Developers it would require to meet the requested deadline. By looking at the team’s previous velocity compared to their capacity (the number of Developers currently on the team), they could estimate the number of items that – on average – were completed by each Developer. With this math, they determined that to meet their goal, they needed triple the number of Developers currently on the Scrum team, taking into account a short-term drop in velocity, which the team expected with such a significant change to the team makeup. Comparing the budget required to expand the team with the business risk of not meeting the deadline, the organization agreed to fund the Scrum team to triple its current size.

Lean Thinking

Lean thinking focuses on reducing waste and focusing only on the essentials. To prepare the team to take on this significant challenge, the Product Owner worked closely with the Developers to order the Product Backlog, ensuring that the most important items were the highest priority. Through refinement meetings with the customer, the Developers, and business subject matter experts, the Product Owner carefully selected what Product Backlog items were most important and less important. Once they ranked the most critical items highest on the Product Backlog, the Developers met to ensure that they could complete those items within one Sprint. By focusing only on the essentials, the Product Owner could eliminate waste, which allowed the team to deliver only the work necessary to meet business needs.

The value of Iterative Development

Scum uses an iterative approach to Product Development, which means that the team delivers usable work frequently. This small change is significant because by delivering usable work, the Scrum team is learning by doing and is not building up technical debt, or unfinished work, which will need to be completed later. By delivering a done, usable increment each Sprint, the Scrum team eliminates waste and can gather feedback on what was delivered, enabling faster learning. The graphic below by Henrik Knilberg is my favorite example of this concept.

The Result

In the end, the team met its goal of delivering the required business functionality by the deadline. I’m confident this would have been impossible without the Scrum framework. By making decisions based on what they knew at the time and adapting to what they learned through experience, the team also became more efficient. By focusing only on the essentials, the team was able to eliminate waste. And, by delivering usable work frequently, the team was able to gain more transparency about the work that was ahead of them, eliminating the accumulation of technical debt.