Practical Scrum Delivery within a Project Deadline
On the surface, it may seem that Scrum and fixed deadlines are mostly incompatible. Scrum fundamentally is an iterative cycle of prioritising and then delivering small increments of potentially shippable work. Priorities can and should change with each sprint, based on value to the business.
However, in some situations fixed deadlines are unavoidable. This could be for commercial or contractual reasons, for example. The only “deadline” in formal Scrum is the end of the sprint. So does that make it a poor fit within a project deadline? Not at all, though it does introduce complexity and potential friction. Fortunately, there are techniques that can be applied to Scrum that ensure we still receive most of the benefits of Agile, while also successfully meeting project deadlines. This article aims to give you some of the tools that I’ve found to be effective in this regard.
Note: this article touches on a number of Scrum fundamentals and assumes that you already understand how Scrum works. It’s worth noting that some of the ideas in this article may differ from formal Scrum. This is also primarily written through the lens of Software Development, though the concepts can be applied anyway.
Why Scrum still makes sense with deadlines
No project ever goes according to plan. The more complex the project, the more true that statement is. Therefore, knowing that compromises must be made, we have a decision to make on where we do that. We have three mechanisms for compromise: time, scope or quality. This leads to a simplified project construct with three approaches.
- Waterfall: fixed time & scope (compromising quality)
- Open budget: fixed scope & quality (compromising time)
- Scrum: fixed quality & time (compromising scope)
We know we can’t compromise on time with a deadline and compromising on quality should be shunned for serious business. In this light, by choosing Scrum, we choose to compromise on scope (I’ll discuss more about this shortly).
Foundations before you start delivering
With Scrum, one of our first objectives is to start delivering “working software” as quickly as possible. That being said, when up against a tight deadline, it’s worth taking some extra measures to ensure the team is able to deliver effectively as quickly as possible.
I recommend that you have the following foundations in place prior to or during sprint zero:
- Have a clear and complete set of user, customer, and business requirements. This provides the team with clear, high-level boundaries on what they need to deliver. It also avoids the need to invest significant time in discovery (investigation, research, detailed requirements, etc.), before delivery gets started (which would resemble Waterfall). Detailed discovery will still need occur as you progress.
- Invest the time in estimation and use a consistent measure for this. Early in the timeline, these will be high level due to the lack of discovery so use a consistent multiplier for contingency. It’s much better to significantly overestimate than underestimate.
- Eliminate as many dependancies as possible. A fully formed, cross-functional team is a critical part of this. Where dependancies sit outside the team or there are multiple teams working on the project, either Project Management or other mechanisms will need to be in place to ensure those dependancies are managed and the team isn’t “blocked”.
- Have your Scrum ceremonies and artefacts in place. These all serve a purpose in adapting the priorities, process and product as you move towards the deadline, while also promoting quality and transparency at all times.
Mechanisms for reducing scope
Scrum allows us to constantly compromise on scope via sprint planning. But within a project with set requirements, we need other mechanisms to help manage this. The two approaches I suggest are:
- At the requirement level by removing requirements altogether or by delaying implementation to after the deadline. While this does allow for more significant reductions in scope, it may have clear commercial or project impacts and will likely need to be negotiated with stakeholders.
- At the user story, feature or component level as component scope. We do this by scaling down complexity (not quality), to a minimum implementation and then adding complexity in consecutive sprints leading up to the deadline.
Both of these can serve a purpose, however the first may not always be possible. Therefore having a simple and effective approach to managing component scope can be critical to success.
Managing scope via Refinement Stages
One construct I’ve found to be an extremely effective tool for communicating scope management, to both team members and stakeholders, is what I’ll call Refinement Staging. By viewing progression through a lens of three stages, Working Software (WS), Minimum Viable Product (MVP) and Minimum Loveable Product (MLP), we create clarity around how we compromise scope via product refinement at a high level. Additionally, this gives us simple terminology for the team to focus their prioritisation practices around.
- WS I approach slightly differently to the common understanding of WS. Here I define this as the absolute minimum required to have a “working” end-to-end implementation of core requirements. So sans low-priority requirements, UI/UX, accessibility, validation and error handling, performance, approved content, monitoring, and so on. It’s not expected to be pretty or easy to use, but it needs to work. Note: we’re still building quality work. In order for WS to be achieved, it still needs to meet the teams Definition of Done (DoD).
- MVP is the bare minimum required to go live in front of users. This is a semi-refined state which we might not be pleased with, but if the deadline is looming, then this is acceptable.
- MLP is a highly refined state and as such, the value of investing additional resourcing in improving may have limited value. Note: ideally MLP would involve solid data-driven optimisation practices, however due to the nature of split-testing, this may take far longer than the deadline allows.
Early in a project the Refinement Staging construct gives us a Scrum centric view of how we target project delivery.
In the graphic above, we can identify the ideal timeline outcome, which would be reaching an MLP state prior to the deadline. However, if you are unable to achieve that and can only achieve MVP in that time, you still have a product that you can accept going live with. Assuming all requirements have met MVP, then this is not a bad outcome. Once we’ve achieved an MLP state, we can move into a more standard Scrum operating model. This is super effective for communicating to stakeholders what they can expect at any given stage of the project.
As a side note, by conducting Showcases throughout the project with stakeholders in attendance, they can see progression through these stages, while also providing early feedback and testing. This does wonders for organisational clarity and transparency.
Where Refinement Staging gets really interesting is when applied at the requirement, Story or component level. By separating these into stages, we get a huge level of flexibility over how we prioritise delivery during sprints. For example, the Product Owner may choose to prioritise core requirements achieving MVP, before prioritising less important requirements meeting WS.
The above graphic demonstrates how you might track the progress of both higher level requirements as well as individual stories, using Refinement Staging. You can see that “Requirement 1” has not reached MLP because its child “Story B” is still at the MVP stage. Whereas “Requirement 2” has not yet reached WS due to child “Story B” not yet being at WS.
The true value of Refinement Staging is the control it gives you in terms of prioritisation and scope management. But it also gives those working on the project simple terminology to communicate with. Often in reality, things are not as black and white as the above table suggest. But by following this approach you can streamline achieving a respectable outcome, hopefully well before your deadline.
Using a Sprint Map to track towards a deadline
I’m well aware that the idea of mapping out workloads across multiple sprints sounds like bad practice from an Agile / Scrum perspective. Perhaps it is, though I don’t believe what I’m going to suggest here is contrary to the Agile Manifesto. Besides, if you have an impending deadline you need to be able to visualise how you’re going to complete your requirements within that timeframe. No doubt, stakeholders will be demanding this clarity regardless.
By mapping out requirements or stories across the sprints leading up to the deadline, we can get a picture of whether the resourcing we have in the team is adequate for the task. Having this clarity as early as possible is extremely valuable. This will be dependant to an extent on the effectiveness of your estimation process; if your estimations are significantly under, then you will need to define more reliable estimates. Additionally, it gives us a place to track any external dependancies.
To be absolutely clear, by mapping workloads across sprints, I am in no way suggesting this becomes an enforced project plan. The Product Owner should still be able to add / remove items or shuffle deliverables across sprints as priorities change. The purpose here is to get clarity around whether you’re going to be able to achieve the deadline so that you can take action if the deadline looks unachievable.
Here you can see we’ve mapped out all remaining workloads across the sprints leading up to the deadline. Additionally, we’ve added story point totals (commitment forecasts), as well as unmet dependancies. Once we have this, the Product Owner can still prioritise and manage scope by shuffling items in between sprints, or beyond the deadline in the Product Backlog.
If you read between the lines here, this ties in nicely with Refinement Staging. We would simply need to apply the nomenclature to our story names. For example, “Req. 1 — Story A” could be named “Req. 1 — Story A — WS.” Of course, you can find your own way of approaching this or use labels, etc.
You may also note that in the example the earlier sprints are more heavily loaded than those leading into the deadline. This gives us a buffer, while ensuring the team has capacity in “Sprint Z” for final testing and release planning if needed.
What’s really critical here is that this is used as a tool for tracking the teams progress. If at any point the team is at serious risk of missing a sprint, or stories are slipping, then that’s your signal for taking action. That might come in the form of reducing scope, adding additional resourcing to the team or if necessary, requesting the team work overtime.
Testing and Quality Assurance
As noted earlier, part of the benefit of Scrum is ensuring quality. This is primarily achieved via good DoD practice. An effective DoD will specify that any completed story has been adequately tested and is of high quality. In contemporary software engineering, this should include automated testing. By ensuring that everything marked as done during delivery is free of defects, this eliminates or greatly reduces the need for extensive testing towards the late stages of the project.
Essentially what this looks like is a continuous approach to testing and QA. As mentioned earlier, if you loop stakeholders into this process as early as possible via the Showcase, you will achieve optimal results by the time the deadline comes around.
In practice, this may be easier said than done. Additionally, if your deadline requires a major release to production environments, then it may be challenging to have complete confidence in your release. As such you will likely want to include some light-weight, manual, end-to-end (UAT, PVT, etc.), and defect management practices to your delivery timeline. The scale of the project should dictate the extensiveness of this testing.
Wrapping up
As should hopefully be clear at this point, the intent of the tools here is to find a middle ground between Scrum and the real world constraints of projects with deadlines. From my experience this is achievable and can be extremely successful. You’ll need strong leadership to steer stakeholders and teams down this path but the obvious benefits will soon have others bought into the ideals as well.
