Managing Customer Expectations

One of the hardest things in agile development is adjusting customer / stakeholder expectations on the way that things are promised.

In waterfall, you would do in depth plans which would forecast which features would be available in the release and when the release would occur. The problem is, they were almost never right. Typically these schedules underestimated the time it would take to accomplish the release. At the point in the release where you discovered this (often quite late), you would start throwing out features (often important ones) and pushing the date. Or even worse, you would skimp on the quality. Perhaps not intentionally, but through shortcuts.

The problem is, after years of doing this, that customer expectations have been set that you can predict what will be available and when. If you commit to exactly what will be available in future releases, you cannot be agile. You don't have any room to make changes. Plus you'll likely over commit and get into similar circumstances to what happened in waterfall.

There are a few ways to address this. My first recommendation would be to fix the date. Given the constant prioritization that occurs in Agile, you will guarantee that you will accomplish the most important things you can by that date. But at that date, you will ship. The fact that you'll stay releasable throughout the release makes it pretty easy (certainly much easier than in waterfall) to hit the date. Hitting dates gives customers / stakeholders confidence in an engineering organization. They enable you to make plans around the release (say getting things ready for a key conference or a marketing launch). If you consistently hit your dates, you will build trust. This is critical.

OK. So you have a date. What do you tell people when they ask what will be in the release? At this point, I would share the prioritized backlog. Mr. customer, here are our priorities as we currently see them. The items at the top are more likely to make it. Those further down are less likely. Do you agree with our priorities? This is a great way to get feedback and refine your prioritization. Often times customers will be upset that their items are further down. But when they look at the higher priority items and you explain why those are higher priority, most of the time they will agree. This collaboration and level setting of what both supplier and customer are trying to achieve can do wonders for the relationship.

Avoid committing to exactly what a backlog item will and will not be. Give yourself room to establish that as you go through it. You might discover that you don't need to go as deep as you originally thought. By not committing to the depth, you give yourself room to be agile.

When can you commit to a backlog item? The best time to commit is when you've already done that in the release. I.e., as the release progresses, you can commit to more and more. From a practical point of view, you'll likely need to commit some of the higher priority items to a key customer or stakeholder. If you must do this (avoid if at all possible), ensure that the item is prioritized highly in the backlog and that you commit as little details as you can to it. Leave room to be agile.

As time progresses, your customers will better understand the approach. And they'll come to trust that you will be taking on the most important things you can in each release.