“Next, we are going to add the ability of the user to …” promises the website.
What do you think? Is the promise of something new necessary?
Or a developer raves, “the next version will increase sales with this very smart new widget”.
Can you use something promised before it is released?
Or a client asks “Will you get this, and this … oh, and this … done by the deadline?” – the correct answer is “no”. A promise is not something that has much value when it is not followed by action. You hear it all the time, “we are going to…”, “the next version will…”
How do we do better?
We only talk about what we have done, what is included in a Sprint, and then only after we have tested it on an integration test on the staging server. If it fails, it fails. We want failure during testing because it means we have coverage. There is no point in releasing code to deliver on a “promise” if, in the end, it is not going to work. There is far more pain for releasing code that is not yet quite right.
RemoteDevelopment.co.uk does not make promises (except in Javascript code). We plan to deliver integrated functionality when it is ready and tested. We plan what is in our Sprint and then it is our own professional pride that delivers those results.
Okay, we do not know what the client will ask for during a Sprint, we add these new ideas to the next Sprint rather than delay planned and agreed to stages of a delivery.
Instead of raving about how it will look in the future, deliver results you have agreed to now. Stable, proven results. Then your client can rave about them for you.