Stop writing proposals ✍️, start selling Sprints 💰
That's the approach I used ten years ago when I was a Scrum Master for a team in a web agency. We developed web applications for external customers.
This topic emerged again some time ago, and coincidentally, I stumbled upon a related blog post I wrote almost a decade ago. I'm still intrigued by our (successful) approach! 😃
Long story short, we had many bad experiences with spending months writing detailed proposals only to discover that things always worked out differently. 🤷 So, we stopped writing proposals and started selling Sprints.
Whenever a customer approached us, we would...
✅ Create the product vision & backlog together. Remember, no contract was signed at this point. Customer shares their ideas; we create a rough Product Backlog and roadmap.
✅ Estimate the product backlog together: "We think it will roughly take use between 5 - 7 Sprints of work."
✅ Start small. As a start, the customer would only buy 1 Sprint. This would result in a Done increment. If they were satisfied, they could buy more Sprints.
✅ Invite customers to the Sprint Review and optionally as an observer to the other Scrum events.
✅ The customers get the entire team, including the tester, analyst, designer, Scrum master, developers, etc. No discussion about hours and roles
✅ Sell Sprints. Because the team is fixed, they also know the costs per sprint, for example, 40.000,-. This means the necessary budget for this project will be between 200.000,- and 280.000,- (given the estimate of 5 - 7 Sprints).
✅ The customer can stop at any moment. By selling Sprints, an advantage for the customer is the possibility of early termination of the contract. When the cost of continuing the project is higher than the additional value received, there is the possibility of just not buying any more Sprints.
In the end, it’s all about trust. Creating the product vision & backlog together, estimating the backlog together, starting small, and inviting the customer to the Scrum sessions are all practices to build this necessary foundation of trust.
When there’s a foundation of trust, selling the entire Scrum team and sprints becomes easier. Of course, quickly delivering valuable, working software is the ultimate way to gain trust.
For us, this proved to be a great way of working. Not every customer liked it. But we built some awesome products with the ones that did! 🏅
Even a decade later, this still seems to make sense. 🤔
What about you? What's your experience with this topic?