Estimations in customer projects from a team with yet unstable velocity

We recently transformed the handling of several (sub)projects in a long running customer relationship into agile.

Why, what was the motivation for doing so? How did you evidence success?

The customer, although generally open to the idea of agile, still needs an fix-price offer for each of these sub-projects, as well as for individual, accumulated “small changes” prior to ordering them.

That's what a Sprint is for, in so far as it constitutes a small project. So why not offer them a fixed price per Sprint? At the end of each an agreed goal will be met and a useful product increment will be delivered.

Hi, Ian,

Thank you very much for your reply. Our motivation for the transformation was triggered by several issues. The main problem was the permanent loss of focus. This was mainly due to the customer's project manager, who was constantly switching between several sub-projects. The deadlines were unclear and were postponed every few days. As a result, important and time-critical features were simply forgotten and the project manager on our side was held responsible. By shifting the focus to clear intervals (aka sprints) and defined deployment dates, we helped the customer to pay attention to the explicit planning of upcoming features. And the team was able to concentrate on the sprint goal without constantly interfering.

I like your idea of offering fixed price sprints with a defined feature set. But how do we deal with the offered functionality that is not finished? The next sprint will follow immediately afterwards. I would say that the following sprint could be offered at a lower price to leave room for the completion of the functionality offered so far, wouldn't you?

I like your idea of offering fixed price sprints with a defined feature set.

That’s not what I’m suggesting, or what Scrum provides for. My suggestion is to fix the price of a Sprint, each one of which will have a defined goal.

But how do we deal with the offered functionality that is not finished?

Work that is not needed to meet the current Sprint Goal, but which may be planned into future Sprints, is ordered on the Product Backlog by the Product Owner. The Development Team will assist with refinement and provide estimates.

II know, and I see what you mean. The thing is, our client is not mature enough to understand the meaning of a goal, at least not yet. I have to admit that I hope we get to that point, but we have to be careful to get there. Right now, from a customer perspective, a sprint goal is nothing more than a select set of features (aka user stories) that the team is committed to. And if the team fails to deliver them by the end of the sprint, for whatever reason, the customer will not pay the bill until they have all the stories from the sprint backlog.

It seems there may be a rationale for incremental delivery with frequent milestones, in so far as the customer can benefit from the improved focus you describe. However, that is not a justification for using Scrum, which is about managing the uncertainty of complex product development. This is done by framing Sprint Goals and then inspecting and adapting progress towards them.

Scrum stands or falls on the usefulness of having these goals and the appetite for validated learning. My advice is therefore to rethink the decision to “Sprint” and what you hope to gain from it. Perhaps it would be better to try and improve continuous flow for example, and defer the implementation of Scrum until such time as the product environment might require it. At the moment, it sounds as if the real “goal” for each “Sprint” is just to get the customer to pay the bill.

Quite simply, overestimate the budget based on the higher-end of the medium to high velocity. 

Thanks again for your answers! You have given me valuable advice, which I will think about.