Quoting with Story Points

Hi Justin,
welcome to the forum.
Scrum does not solve the problem that you cannot give a good estimation for the development of a complex product.
But a good practice to develop this estimation is based on inspect and adapt.
1. Estimate the backlog in story points
2. Do the first sprint
3. Measure how many story points you have accomplished
4. Do an extrapolation for the remaining backlog (first approximation)
5. Repeat 2-4. The approximations will get better, which reflects the experience you are gaining.
Usually the backlog will change over time. Items will be added, removed, described more clearly etc. This will be reflected in the estimations as well.
So you cannot give an upfront estimation, but those you can give will be brutally honest.
If you need an upfront estimation, you will have to do it the usual, non-agile way, including all the well-known risks and uncertainties.
Best, Ludwig

Justin,

Having implemented Scrum for deliver to customer within on consultancy I can definitely feel your pain. On the one hand you need to be able to give your customer an estimate and on the other, as Ludwig implies, any estimate that you give is pure fiction. The reality is that this is a contractual discussion rather than a philosophical one.

Part of this is how you present it and the other is 'the way that things are done' for you customers. It is ultimately a training issue on both sides and you need to figure out how to sell agile delivery. As to estimates: If you have a team of 4 and your daily rate is $500 per person then your rate for a two week sprint is $20,000. You may be able to reduce that as you can now calculate on having 4 folks off the bench at once, but that's for your business guys to figure out.

Now that we know that this team is 20k per sprint we can go to the customer and say:

"We think that this work that you want us to do is about 6 Sprints worth of work. As this early in the process this estimate has a very large margin of error I would recommend that we budget for 10 sprints. This would be a total of 200k. If you want to set that as the limit we can work towards that.

Now we plan to provide Working Software at the end of every Sprint so if we have met the requirements before the end of the 10 sprints then you only pay for what you use. Indeed we are so confident that you will like not only this way of working, but also the output, that we will allow you to cancel with only one Sprints notice."

This is a shared risk model that gives the customer warm and fuzzes that they are not locked into the whole 200k but are instead only committing to 40k up front and adding 20k blocks of time as they see the value that is being delivered. You may want to manipulate this based on the quality of your teams, the work delivered and the customers perception of value.

To start to achieve this, and make no mistake it will take tome to change not only your internal processes but your customers as well, you will need to focus on changing the contracts that you enter into. Look at some of the available 'agile contracts' and work with your lawyers, accountants and contract writers to bring them around.

Its hard but I have seen it done and work well.

Luwig and Martin are right, and I concur that you should try for a more agile contractual model based on incremental funding. Here's the sweetener for your client: they will no longer be held hostage to the Change Request mechanism, as changes in scope can be accommodated.

That's on top of the opportunity to benefit from an early and incremental return on investment, plus the ongoing reduction of risk and limitation of exposure by capping potential losses to a window of one sprint.

NB you might want to google for the work done by Gabrielle Benefield and Susan Atkinson on agile contractual frameworks. A couple of years ago I wrote an article on this subject:

https://sites.google.com/site/wicmitchell/home/from-the-agile-manifesto…

Thanks for the feedback and information guys, Could this be a place to use the Minimum Viable Product?

The term Minimum Viable Product (MVP) can be used in at least two contexts. Let's consider what are perhaps the two main ones.

Firstly, MVP can be seen as the sum of all mandatory ("must have") items in a MoSCoWed requirements set. If this is the sense in which you are referring to MVP, then there can be business risks in applying an agile contractual model. The danger is that if you agree to deliver a Sprint Backlog that consists entirely of mandatory items, you risk not meeting the associated Sprint Goal. In other words a Development Team, by accepting such a backlog, could be setting the sprint (and therefore the project, which is being funded sprint by sprint) up to fail. There may be insufficient flex to recover should the team's estimates prove unrealistic. The general guidance with MoSCoWed requirements is not to exceed 60% "must haves" in a time-box. This clearly has implications if using an agile contract to deliver MVP in this sense of the term.

However, the term MVP can also be used in a leaner sense. Here, an MVP is the minimum needed to establish the market viability of a product. That MVP could consist of wireframes, manual processes, and a great deal of smoke and mirrors. Only if the MVP proves viable will further investment be made in product development...a process known as "validated learning". This is a more agile definition and use of MVP, and it is one that is well suited for incremental funding.