Skip to main content

Can Scrum Work for Hard Deadlines?

July 6, 2021

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. 

 

About Mary Iqbal  

Mary has trained more than 1,000 people in Agile, Scrum and Kanban.  She has guided the Agile transformation for organizations with more than 60 teams and has led the creation of new products from product definition through self-organization and launch.  Mary is the founder of Rebel Scrum, a consulting company that helps teams transform to Agile and provides training and coaching services founded upon practical experience.  Rebel Scrum has experience in large-scale agile transformations in a variety of environments including technology and business transformations.  Signup for one of Rebel Scrum's upcoming public scrum training classes or contact us to discuss private Scrum training and consulting options for your organization.




 


What did you think about this post?

Comments (9)


Balaji.M
02:08 am July 7, 2021

Hi,
I don’t see the Incremental aspect being covered here. Please can you share how it was handled ?
As in Iron Triangle, in this case Schedule is constant and want to know what trade offs for Cost and Quality? Cost I can see additional team but what practices were adopted to maintain Quality? Please can you share the learnings on these two aspects as well.
Thanks
Balaji.M


AgileJar
04:16 pm July 7, 2021

Quality (or Scope) was adopted on Product Backlog level - by prioritisation and focusing only on essential items required by Business Case.
It was a technology product with fixed time. Cost could be easily calculated as team cost (7 Devs + SM + PO) which then was almost tripled (triple the number of Devs required).
In the end they still had to manage the scope to deliver what was required based on the learnings from short delivery cycles.


Balaji Muniraja
08:11 am July 8, 2021

Ok, since it's a technology product, with help of Scrum you would be able to implement. One thing, being technology product i wanted to know is how much or did you ensure DOD is met at the end of the Sprint and how much carry overs see during implementation.


AgileJar
08:38 pm July 8, 2021

According to Scrum Guide:
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

That means, it has to be met with each Increment = at least one per sprint, at its end. Without that, you cannot inspect results of the Sprint and adapt learnings in the next iteration.

I do not know what you mean by "carry overs". Could you explain? Again - in Scrum all work which was not completed within sprint (completed = meet DoD) is moved back to Product Backlog.

If you would like to know how many from the original scope is delivered in end product, then again - in complex environment, you want to meet customers needs and you have to adjust your product based on the user feedback. In that case, this question cannot be answered.


Abhishek Vishwakarma
01:56 am July 10, 2021

Could you please put more light on below question from Balaji?
"I don’t see the Incremental aspect being covered here. Please can you share how it was handled ?"


Mary Iqbal
05:10 pm July 10, 2021

The team did have a definition of 'done' which had to be met each sprint. A definition of 'done' is the minimum amount of work that the development team needs to do for a Product Backlog Item before it can be considered 'done'. A sample definition of 'done' might include such things as ensuring that unit tests are conducted or ensuring that code reviews are conducted.

Your second question was how did the team ensure that the definition of 'done' is met at the end of the sprint. The answer is that the Developers plan how to create an Increment that meets the Definition of Done by the end of each Sprint. How this is done is determined by the Developers, but the Scrum Master may coach the team in self-management to accomplish this goal. Getting to 'done' by the end of each Sprint is the primary measure progress.

As to the question of what to do with incomplete Product Backlog Items (commonly referred to as 'carryover'), at the end of the Sprint, the team should re-estimate and return them to the Product Backlog. I will be releasing an article to discuss this topic more fully. Many teams in my experience focus too much on whether each Product Backlog Item selected at Sprint Planning is completed by the end of the Sprint. The more important measure of progress is whether the team met the Sprint goal and delivered a 'done', usable Increment by the end of each sprint.


Mary Iqbal
05:18 pm July 10, 2021

To define Incremental delivery: a good analogy is if a team wanted to build a web form with 5000 fields which saved to a database... In traditional software development you might build first the database, then the data layer and then the user interface and the customer would not receive the form until all 5000 fields were saving to the database as expected. With iterative development, work can be planned differently. In one sprint you might deliver a form with five fields, but those fields fully work and save to the database as expected. Then in future sprints the team might add additional fields to the form. Each sprint a completely 'done' and usable increment is delivered. Each sprint is a step towards the goal of delivering a form with 5000 fields which save to the database. This is the approach which was utilized.

The Iron Triangle that you refer to is Dates, Dollars and Deliverables (Schedule, Cost and Scope). In the example provided in the post, Schedule was fixed but Cost was flexible. Scope was also somewhat flexible in the sense that the Product Owner had to carefully order the product backlog to ensure that the most valuable work was completed first. Note that Quality was NOT flexible because quality requirements were established by the definition of 'done' which did not become less stringent.

Incremental delivery was key to the success of this initiative because it helped the Product Owner ensure that the Product Backlog was ordered so that the highest value items would be addressed next; it helped the development team to ensure that technical debt was not accumulated during the delivery phase, and it helped the development team by ensuring that they were able to continuously improve at the end of each sprint.


Mary Iqbal
05:19 pm July 10, 2021

Thank you for the note - I posted a response just now - please take a look and let me know what you think.


Abhishek Vishwakarma
06:46 pm July 12, 2021

Thank you so much Mary. This answer helps.