What happens to the deadlines in Scrum?
Hello All,
First, I would like to thank in advance the fact that you took the time to read my question.
Recently I obtained the PSM I certification, and started providing Scrum trainings inside the organization. One time a coworker asked me how is possible to know when is the project going to be finished, or how do you set a deadline to the project overall. My answer naturally was, as established in the Scrum guide, that Scrum is based in empirical control theory, and that instead of having a plan, you just track the progress overall and estimate the duration of the project based on that. After that he still wanted to know what happens if the customer wants to have an official contract in which an ending date is stipulated.
Regarding to your experience, what happens in this case?
Once again, thank you for helping me with this topic.
Kind Regards.
For me, the easiest answer is to draw a comparison between traditional project management (waterfall) and Agile (Scrum).
There are basically four variables within a project that can be adjusted to try and keep to a predetermined schedule. They are: Time, Cost, Scope, and Quality. In traditional project management, any of these 4 control knobs can be tweaked to stay on target, even though the other attributes may suffer as a result. For example, I can reduce the duration of a testing phase to keep certain dates "green", but quality may suffer as a result.
In Scrum however, three of these four attributes are fixed. Time is fixed by the length of the sprint. Cost is fixed by the stable Scrum Team (and equipment/tools used). Quality is fixed (each item must meet the Definition of Done).
The only variable in Scrum is Scope. You are free to establish delivery dates, and base them on projections that leverage a team's velocity and PBI estimates. The only variable is what will actually be delivered by that target date.
In an ideal situation, everything planned will be delivered, but if there are scope changes (i.e. - new high-priority features identified), or other factors/impediments affecting Sprint Goals and/or forecasts, only a portion of the original scope may be delivered. Even so, it should be a significant % of the original plan, and should consist f the highest value items in the project.
Also, under Scrum, the option should be available to deliver frequently (end of each sprint), and there is the likelihood that at a certain point, the business may determine that "enough" of the feature has been delivered, which may result in a shorter overall project time frame.
One time a coworker asked me how is possible to know when is the project going to be finished, or how do you set a deadline to the project overall.
The project will be finished in one Sprint.
The Scrum Guide makes it clear that a Sprint can be thought of as a project with no more than a one-month horizon. The customer will then have the opportunity to decide if further Sprints would be worthwhile.
It can be prudent to inquire into how work will therefore be prioritized, so that maximum value can be released as quickly as possible and lessons drawn from it.
@Ian, I agree that is the approach according to the Scrum guide. And I think that approach works well for projects that don't have much in the way of non-recurring engineering (NRE) or upfront cost. However, what about for projects that do? Is the expectation that NRE can be avoided on all projects if you take the agile approach? Or do those kind of projects lend themselves better to (dare I say it) waterfall? Regardless, let's say that a project has some high non-recurring costs (e.g. for hardware, infrastructure, licensing...). Is it reasonable to expect a customer to fund this kind of project as it goes? Or are there any guidelines on how to approach both budget approval and roadmapping (with target milestones or deadlines) on those projects in a more agile manner?
My advice is to view this as an innovation problem. Think of how a start-up might provision such things as hardware, infrastructure, and licenses before they have any revenue or a sustainable business model.
They might seek venture capital from stakeholders, and/or frame an initial MVP to use no more resources than are at their initial disposal. They might take out a loan. They might leverage cloud-based services or providers offering freemium versions. At any moment in time the startup would have a clear picture of how much “runway” they had left (e.g. how many Sprints they could fund) before their product has to become self-financing.
A large and well-funded organization might take this problem out of the hands of teams and just fund the costs separately. On the other hand they may recognize that, at their scale, so-called non-recurring costs do in fact recur quite often. For example, they may set up an agile studio or innovation lab which provides a suitable host environment for their various new initiatives.
@Ian, thanks for the reply. Let's take the case you used where they have to take out a loan. At the beginning of a project, they may know how many sprints they could fund, but they probably don't have any sense of how much of a product can be built in that number of sprints and whether it will be close to self-financing by then (assuming only coarse estimates at the epic level, and/or a team with no historical velocity). So how can they feel comfortable taking out a large loan in that case?
If I may add my thoughts...
It's all about value and incremental discovery. At the beginning of a project, you will have ideally identified the MVP. Note there's a critical principle (Pareto Law) according to which 80% of the benefits come from 20% of the work (features).
Of course, nothing's set in stone, as you start delivering the increments, you learn more and you could potentially adapt the MVP or that 20%. In my experience, there are extremely slim chances the MVP would be completely replaced once discoveries kick in - as more is learned on a gradual basis.
The famous cone of uncertainty "exists" for a reason. There are so many unknowns at the beginning of a project that you simply can't say - yeah, based on the estimates, the project will take 6 months to complete and the product to be 100% per initial specifications. Some businesses (leadership) understand this, others don't. It's actually more to do with trial and error.
Initial estimates are most always wrong (and usually on the lower side - effort is generally higher as more is uncovered, priorities change, etc) hence the first few sprints are critical. The mindset should be - ok, what value can we forecast to get (and, surely, what can we learn) from, say, 3 increments (3 one-month sprints)? We'll take a loan for 3 months and review accordingly. After three months you'll know way more than before (cone of uncertainty), you'll get feedback, discover a few interesting things, you'll be able to forecast better, you'll have an understanding of velocity, etc. Yeah, I know, wishful thinking for many organizations - but some actually do it.
Let's take the case you used where they have to take out a loan. At the beginning of a project, they may know how many sprints they could fund, but they probably don't have any sense of how much of a product can be built in that number of sprints and whether it will be close to self-financing by then (assuming only coarse estimates at the epic level, and/or a team with no historical velocity). So how can they feel comfortable taking out a large loan in that case?
By being scrupulous in their choice of creditor and about how risk and opportunity will be shared. They would be unlikely to go a regular bank to take out a loan for their project, for example. Assuming a bank was willing to extend a loan at all, it would probably be secured against non-project collateral such as the personal assets of team members. That isn't the deal here.
It might be more plausible to approach angel investors, or possibly venture capitalists, for a loan. Such people might be rather more likely to understand the risk and opportunity of the prospect. The risk they take on may be offset by a stake in product equity. They are somewhat more likely to inform themselves about the product, and hence be in a better position to make informed decisions about how much runway they realistically need to fund.