How to Say "No" to Customers Without Actually Saying "No"
In an Agile environment, the ideal practice in communicating to Customers is through the Product Owners. One of the most important responsibilities of a Product Owner is to set the expectations of a Customer and provide them with timely information on when an epic or story will be worked on and when it will be completed. At the same time, the Product Owner needs to be able to cascade the information clearly to the Team. From my experience, a Customer's attitude may differ, it can be from extremely lenient to extremely stubborn. What if you are faced with a Customer who is stubborn and can't take "no" for an answer? What will you do?
What are the most important stories? Everything!
The most common scenario is when you ask a Customer which are the important stories that need to be delivered. Guess what they will tell you? ALL are important. I have encountered these kinds of Customers from different Companies that I have worked with before. Who can blame them? That is human nature, to want everything if you can have them.
A personal experience that I had was when a client gave us a Business Requirements Document with everything they wanted to have. They wanted everything completed within 2 months, which I knew was impossible given the size of it. With the reputation of this client, I knew for a fact that they won't take "no" for an answer, so I had to think of another way to bring it up to them. I asked the Team to breakdown the Business Requirements Document into small user stories and came up with a story map.
We presented that to the client and told them we want to deliver everything in it, but if he wanted to have some features out in Production within 2 weeks, what would those be. He looked surprised and asked if we were sure that we can deliver something in 2 weeks' time. We said yes, we will deploy something to Production after 2 weeks, but we need to know from them what they thought was the most important story for them. That's when they arranged the stories in sequence from the most important to the least. That's when we taught them the concept of MVP (Minimum Viable Product). From thereon, they understood our approach and they were happy that in as fast as every 2 weeks, we were able to actual working results.
As a Product Owner, you need to make the Customers understand that in Agile, we deliver every 2 weeks so that they will be able to see the results in a short span of time and to have them working in the Production environment soon. With a delivery frequency of every 2 weeks, they can also feel their money's worth. And what's good is if they have something they need to change or improve, it can be done already in the next sprint.
For us to be able to have something delivered in 2 weeks, we need to understand the priority from them. We can list down all the stories in the pipeline, and ask them the value of each story to the business (others would call this Cost of Delay), 1 as the least important and 10 as the most important. Some examples to measure business value are: which story will provide the biggest revenue to the company, or the one that will enable work to be more efficient (such as automation), or the one that will the biggest impact to the vision of the company. We want to deliver everything to them, but in reality, there is a limit on what each Team can deliver. What we want Customers to realize is that we are not saying "no", but we want to prioritize the stories, in order for the Teams to have focus and deliver the top-most priority at the fastest possible time with the right amount of quality.
We can use the WSJF (Weighted Shortest Job First) method. After the Customers have given the value rating for each story, you can ask the Team to estimate the time needed to complete each story. By dividing the Value (or Cost of Delay) over the Estimated Time, you will get the WSJF result. The story with the highest WSJF score will be on the highest priority in the sequence. If there are 2 or more stories that have the same Value, the one with the lowest Estimated Time will have a higher priority. You will see that it will have a higher WSJF score. By using this prioritization method, you are helping the Customers make prioritization decisions easier.
Another scenario that Customers tend to do is to tell you what they need without providing the necessary requirements. This will leave the Team guessing and will take time to keep on coming back to the Customer in the middle of the sprint, which will also affect the velocity of the Team and their sprint commitments. Of course, we cannot tell Customers "no, we cannot do it because the requirements are not clear". We need to realize that our Customers are not the ones who are going to deliver the job, so it is possible that they thought that the requirement they gave was already clear, when in fact, it is not.
I had a lot of similar experiences on this with multiple clients. When we asked for more details on the requirements, they would say "it's all on the document, just read it". What our Team did was to follow what was in the requirements and showed the result to the client. The client's facial expression was "what is this? This is not what we asked for". That's when I explained to them that by giving plain requirements, this is what happens. Time is wasted because now the Team needs to re-work on it. Afterward, I asked our Product Owner to sit down with the client to understand the details and agree on the acceptance criteria, wherein if the Team satisfies the acceptance criteria, it would mean that the client will be happy. When the completed stories were presented in the next demo, the client was satisfied and realized the importance of the exercise done of providing the details requirements.
As a Product Owner, we need to extract the information from our Customers as early as possible. Ask for more detailed requirements, if needed. Ask for the acceptance criteria. You may also run them through the proposed test scripts and workflow, to ensure clarity. That is one way to have the confidence that the Team is aligned with the expectations of the Customer. The Customer will understand that we are doing this to make sure that we avoid errors or unexpected behaviors when the stories are showcased to them. Companies know that every time a story needs to be re-worked on, it will cost more to them, as compared to when we are able to deliver the expected requirement right on the first pass. When the Customers realize the cost that entails for every re-work, they will know why we are keen on having clear requirements and acceptance criteria before giving it to the Team.
Remember, we do not say "no" to our Customers, but we have different ways to help them realize how we deliver in an Agile way, to be able to provide them with the most valuable stories in the fastest possible time and still considering the quality of our delivery. We need to help them understand the way we work, in which we are trying to maximize the efficiency and productivity of our Teams. By doing this approach, the Customers will not feel that we are forcing them to follow our ways, we are merely showing them our work perspective for them to understand why we work this way, and assist them in appreciating it. When your Customers see the benefits to this approach, we will be able to align the Customers to how we work without having to say "no".
Stanley has more than 15 years working in the IT industry, with expertise and focus on Agile coaching and transformation, at the same time managing programs and project teams. During these years of experience, he has proven himself in guiding people and processes to deliver quality solutions. He focuses on the team dynamic and delivery to motivate the organization.
Connect with Stanley Ang on LinkedIn