How to plan for fixed bid during contract time?

Question

During Contract time, we are given requirement details and we dont have stories.

If we have to go for fixed bid contract, do we create stories at time?

I doubt - as no one has time at contract stage to create stories and decide on story points?

So, how do you approach for this?

Do you create epics and give story point to it and plan based on that? But I believe epics can not be broken into stories that are equivalent size. StackLink

or

Do you just estimate development effort in a waterfall way? And build a cost around it and sign contract? In the plan you mention Agile plan will be given after stories are created and velocity known. But i dont think this can really work out always?

StackLink

or

Is there some other way?

Answer 1

Tl;dr;

Do relative sizing on features.

To Elaborate:

When you’re looking at a fixed-bid contract, you’re saying “It will take me no more than this much money to do deliver the full scope.” This is problematic in Agile because we recognize that most software projects do not understand their scope until very late in the project. This isn’t the result of Agile – most waterfall projects don’t understand their scope either; the difference is that Agile doesn’t pretend to.

Feature Sizes

When we look at the overall size of a project, we still want to use relative sizing. You may have a baseline feature from past projects (you always have to start with something you’ve really done) and that may be a medium. Then you can look at features on new projects and ask “Is that about the same size, a little larger, a lot smaller?” Your development group will have a velocity at this level just like it does at the sprint level.

If your team has an average sprint velocity of around 30 story points and you have 3 8-point stories and 4 5-point stories, they’ll probably complete those in 2 sprints. The feature sizes work the same way. Medium features (if you’re doing relative sizing properly) will cost around the same with a certain margin of error.

Why Not Just Add Story Points?

If you detail out all of the stories and estimate them all, you assume that the scope is fixed and you thoroughly understand that. As soon as you assume that, you’re taking on incredible risk to yourself and your client and defeating many of the core principles of agile.

By looking at feature size and applying relative estimation there, you’re leaving plenty of room for uncertainty and modifications to the details. How Can You Start? Look at your past work. Apart from using a past feature as a baseline, you can also retroactively do some relative estimation to give you a base of data to work with. There’s a big pitfall here though: you know how long it took – you’ll naturally want to use reality to influence your estimates. You can try to consciously avoid this or maybe have people do the relative estimation who didn’t work on the feature.

Be Warned

Just like the way messing with team composition throws story point velocity off and story points aren’t comparable between groups, if you constantly change up your development group’s structure or split people on projects, this approach will fall apart and you will not be able to see trends in feature cost.

Answer 2

Charge for preparing the estimation

You said:

...no one has time at contract stage to create stories and decide on story points?

When I call a vendor for a home improvement project, their approach goes like this. A representative will visit my home to go over these things:

1. Explain the various product options and let me pick the ones I want.
2. Explain what obligations I have, while they do the work, such as moving furniture or not have access to the kitchen for a day.
3. Take measurements.

The vendor will charge me for preparing this estimation. Though they will typically offer to take this estimation charge off from the final contract price, if I place the order with them. Some contractors give free estimates, but often I find the reliable experienced contractors don't give free estimates. The newcomers who are trying to make an entry into the market are the ones offering free estimates.

You asked:

Is there some other way?

Yes. Charge for the estimate and do a proper job. That is the practice in mature industries working successfully for a long time.

Answer 3

In addition to user stories, create a requirements document:

It would have been challenging and risky for us to estimate work based solely on these user stories and then to commit to a fixed price contract. We needed more information, which we could get through conversations with our customer. But we also needed to document some key assumptions and decisions that would result from those conversations. What we did was identify a small number of high level acceptance criteria for each user story. Today I refer to these as conditions of satisfaction for the story. We then produced a requirements documents that included each user story along with its conditions of satisfaction.

In addition, use specific wording about how post-production work will be done in the Assumptions section of the RFP:

We assume that any enhancement/change request communicated after the product/ release backlog sign-off that is the focal point of this agreement will be treated as a project change request (PCR). Management of a PCR will be outlined in the change management plan. A change request should require removal of scope (i.e., a like-for-like or equal-size story) from the “would like to have” 40% scope section of this contract of equally valued items, or it becomes a re-pricing consideration. If new scope is added, it will increase the stated scope in the scope section of this agreement. Either way, the changes to scope will be handled as a project change request.

This sounds like an agilefall project:

We have a product backlog with priorities, but we start working on a release with a long list of features already committed to the business.

We know our product release dates several months in advance. There's a long list of target dates that must be met before the release date.

We demo our software in development to customers, but only after we're happy with it. By the time we get around to having a demo, it might be too late to change much.

References

• AgileFall: What is AgileFall?

• An Agile Twist: Fixed-Bid Pricing (pdf)

• Writing Contracts for Agile Development