Scrum in fixed bid contracts - When should the PB be ready in its refined state?

Why do you want to use Scrum in this situation?

It seems like you've already made an estimate of 6 months and made a bid based on that duration and however you compute the cost for a team. Given the point in the effort when the estimate was made (see the Cone of Uncertainty) and the fact that the people doing the work were not involved in the estimate, this estimate is probably wrong. However, that estimate has already turned into a commitment.

Since you have an estimate-turned-commitment, what is the advantage of using agile and adaptive methods, like Scrum, to execute on the delivery of the product? The best possible outcome for using Scrum would be that you identify earlier on that your initial estimate is wrong. By starting to do the work, you will likely discover that some of the described functionality and mockups don't reflect what the client and users really want - either the requirements are wrong or there are missing requirements.

Although identifying the need to change is good, is it feasible to change? How will your client react when, late in month 1 or month 2 or even month 3, that you begin to realize that it is not possible to meet that 6 month go-to-market date with the planned features? Is there truly an opportunity to replan and reprioritize to have something in 6 months? Or an opportunity to adjust the projected delivery date based on what has been learned and accomplished? Or an opportunity to cancel the project and redirect the remaining funds to a more valuable effort?

If you cannot adapt and learn, agile methods like Scrum add unnecessary overhead. Why bother to do the work necessary to keep the product in a potentially deliverable state and do frequent reviews if you cannot act on the feedback? Dropping the associated inspection and adaption events from Scrum would give you more time to work - depending on your planned Sprint cadence and event lengths, potentially an extra few working days a month which could add up to a week or two over the 6 month schedule.

If you can adapt and learn, then you should expect that you won't have good long-term forecasting. There are simply too many unknowns to forecast multiple Sprints into the future so the notion of predicting a completion date isn't possible. You could consider using burndown rates and the flow metrics of throughput and cycle time to attempt to forecast, but realize that any changes to the Product Backlog would impact the amount of work remaining.

I would say the backlog management will remain the same as with any project.

"we will not know what is the velocity needed to complete the project"

I think this is where you would need to manage expectations. Since you have a fixed budget (deadline) You will have to accept that the delivered functionality is variable. But the question will be what do people expect when you talk about "complete the project". Your backlog can still be very long at the moment of completion. There will always be more changes that might improve the product.

I would suggest setting up some goals, preferably measurable, with your customer so everyone is one the same page as to what is considered complete.

Backlog management should be done the same as with any project. Only try to refine just as much as is necessary to keep the team fed with work and make sure this work comprises the items that bring the most value (Keep checking the goals for this). That way the remaining backlog at the end of the project will contain less important items. (which gives you an excellent opportunity to discuss selling them an additional sprint)

Just make sure that the stakeholders are always involved with the progress and use their input on deciding what to focus on for next sprints and challenge them when they veer to much from their original plans to make them see the consequences of their choices (again use the goals set at the start).  That way scope changes are perfectly fine since they should add up to a different, but better end result.

If after all this the result is not satisfactory then you might just have underestimeted the work, I would suggest revisiting the estimation process.

Hello Thomas, thanks for your response.

Scrum deliver model was decided before i joined the project even though i dont disagree with you.

To your question - Is there truly an opportunity to replan and reprioritize to have something in 6 months?

I am proposing that atleast we should plan our work in a way that MVP is ready before the go to market if not the entire backlog. Even for this, do you think we should prioritise and groom the backlog (for mvp) asap for better tracking and visibility? The entire backlog seems impossible now.

Do you think and this question is to Casper too, is Scrum/incremental development approach applicable for Fixed bid projects? If yes, how the contract should be devised including payment terms etc..

Some of the answer depends on how you define "Fixed bid projects".  Are all 3 elements (time, currency and scope) of the equation fixed? If so, there is no need to use an agile method of any kind.  You just work as much as you need during the fixed time to produce the fixed scope so that you can collect the fixed amount of currency. If by chance there is some flexibility in the element of scope, then the following would be my suggestion.

If you talked to your accounting department (which all organizations will have) they could probably give you a number that could be used as a standard cost for a team of individuals for a fixed period of time (ex. US$3500/person for a 2 week period).  Using that number, you can determine the cost for a team of X people for that period.  The fixed cost bid would then be a negotiation of how many fixed periods of time does the customer want to pay for you to provide.  The output would be what ever can be created during that period of time.  Since the output of every Sprint is at least one usable increment of value, and the stakeholder would be involved along the way providing input and course correction at every Sprint Review, they would receive something usable at the end of the fixed period of time for the fixed amount of money that they wanted to spend.

Scrum deliver model was decided before i joined the project even though i dont disagree with you.

The Scrum delivery model was misunderstood before you joined. They thought it applied to work that is pre-defined up front. In truth, Scrum is about learning to build the right thing at the right time. Work is emergent.

This means they haven't "decided" to use Scrum. They can't. They haven't put themselves in a position to use it and they haven't got it. They may have the pretence of using it, but that "decision" is an organizational conceit.

My advice is to tackle the misunderstanding. A broken implementation of Scrum will not deliver Scrum outcomes. Instead, they'll get the stage-gated outcomes they've always experienced and a disillusionment about agile practice.

Just for the record Product backlog is never ready. Its a flow, not an object.

Try to give it a thought, and things will get easier.

Even if the contract is 'fixed' it doesn't mean that there are no uncertainties and risks. On the contrary, those are way bigger. Thus in my opinion Scrum approach is still desirable. Through transparency and inspection, you can discover quickly deviations from the initial plan. The adaptation will be obviously way more difficult due to the contract constraints. However, for both the vendor and the client, it is way better to discover the deviations quickly.

When approaching such projects with Scrum, it is important to make sure that everyone understands the constraints involved

There are opportunities to replan and reprioritize, even in a 6 month effort. If you find agility useful, then I'd say that there are at least 4 opportunities to replan in a 6 month effort. If you're using Scrum, there are at least 6 opportunities. The only question is how effective is that replanning and reprioritization going to be. For replanning and reprioritization to be effective, the work or the deadlines need to be flexible.

If you are able to clearly define an MVP that is a subset of the backlog, then you can put those Product Backlog Items up earlier and start there with refinement. Then, as you deliver, you may gain some more information about what a true MVP looks like, you can adjust your Product Backlog accordingly. You may find that what you initially thought was an MVP that you would need for go-to-market isn't really that minimum MVP for go-to-market and you can plan accordingly. However, if you do need that full backlog for go-to-market, then it doesn't make much sense to go through that effort.

Regardless of if you decide to use Scrum (or some other agile method) or not, this really doesn't have an impact on payment terms. Your customer is willing to pay for 6 months. If you use Scrum, establish a Scrum Team with the necessary people and start Sprinting for 6 months. When you get close to the end, you can review and, if appropriate, discuss renewing or extending the contract. Otherwise, there will be a final Sprint, after which the team will go onto other work or disband.