Skip to Content
Personal Insights
Author's profile photo Carmen Constantinescu

Signs that you’re doing well in your Agile project. Product Owner says “no”.

Any journey is made of small steps and as Agile Coaches, we need to value and celebrate all the small changes that are leading to the large scale Agile Transformation.

As spring is coming and our hopes for the best are blooming inexplicably sometimes – like the trees in our backyard – I’ve decided to focus myself on creating a list of good signs showing that the agile coaching endeavor is on the right path.

I am a Business Process Consultant with specialization in SAP Activate and Agile methodologies, supporting implementation projects for SAP S/4HANA and SAP Commerce solutions. I have delivered hundreds of hours of trainings on Agile and workshops to SAP customers followed by even more days of coaching on the job, as SCRUM Master or as both Agile Coach and SCRUM Master in the previously mentioned implementation projects.

I’m coaching for agility adoption teams in medium, large and very large size implementation projects in which many of the members are only meeting for the project duration, are coming from several companies and very often, from different countries and cultures. Some of these companies are having already the Agile mindset and are already implementing Agile practices and some are very new to it. I’m working with management, business and technical consultants and the most satisfying moments in my work are when the people I’m coaching to agility are living their “Aha!” moment that pushes them one step further towards agility.

That sudden revelation one has is my indication that we’re doing well in our transformation!

Applying the “build to budget” concept in the Agile implementation project can be quite a complex demand for somebody new with the Product Owner role. In the projects I was part of, the Product Owner role is usually taken by a Business Process Owner, a Business Process Expert or by an IT Lead who is knowledgeable, has enough courage and gets the delegation to decide on the behalf of his company.

If a new User Story appears as needful for the solution or the complexity of an already identified User Story is higher than preliminarily estimated, in a “build to budget” approach means that something needs to be taken out from the backlog to make room, to accommodate and to adapt to the news.

In this case the Product Owner needs to say “no” to a User Story and to the people in his organization who have raised it.

At SAP, in an implementation project, we’re putting the Customer in the driver’s seat, giving him the decision on what is best and valuable for his organization.

We’re doing this by giving the Product Owner role to customer’s representatives that we need to coach and support to make educated, timely and effective decisions within the time lapse that very often is less than a Sprint(2-4 weeks).

The Product Owner role is usually new to its beholder and it is coming with a lot of pressure. Very often it takes time until a Product Owner is reaching decisions in total self-confidence and comes to say “no”.

There’s an important number of perspectives that the newly appointed Product Owner needs to consider before finding his own way of looking at his backlog so that he can decides what is staying and what is going out from the release!

On top  of that, he will live the after-project life to run the business with the solution that he has decided for him and his colleagues and  he’ll be reminded on a daily basis about the decisions taken.

The Product Owner is representing a community of users – his stakeholders – and that’s making his job even more complex when he needs to say “no” to a User Story.

To support the Product Owner in his decision making process the Agile Coach must understand the customer’s decision making culture and the Agile maturity level of the company.

The Agile Coach is helping the Product Owner, in his personal and company specific context to find the lever that brings to his company a new solution and enhanced agility.

Although he’s not directly appointed to do that, the Agile Coach in SAP implementation project delivered with Agile is actually supporting the bigger, overall Agile Transformation in the customer’s company by teaching and supporting the Product Owner to embrace the agile behaviors when coaching him.

Here below I’m summarizing the most frequent aspects that the Product Owner needs to factor in his backlog management decisions along with the means and actions from the Agile Coach.

The Agile Coach must help the Product Owner on finding his own approach to say ‘no’ to his own organization.

The first time the Product Owner says in full confidence “no” to a requirement is typically after an “Aha!” moment and that needs to be remembered and celebrated!

I’m inviting you to use this blog to leave your thoughts and opinion on this matter and to share your experiences from situations when your Product Owners had to say “no”.

Was it a celebration moment?


I’m also taking the opportunity to promote here the newly created  SAP Activate blogging community and the SAP Activate Q&A community



Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Bob Byrne
      Bob Byrne

      Great Blog post here Carmen Constantinescu ... Great to hear other PoV on how we evolve SAP Activate to the customer. Great blog for all seasoned and new product owner roles in SAP implementation projects. Thanks for the promotion to our new tag, where you can follow all SAP Activate blogs on the SAP Community platform.

      Author's profile photo Jan Musil
      Jan Musil

      Carmen Constantinescu thank you for taking time to share your experience with the community. This is great blog post. As you write, saying "no" is harder than saying "yes" and it shows maturity and vision. It gives the PO ability to steer the direction of the implementation by deciding what to emphasize. Often it is easier to say "no" if there is a strong support from sponsor and trust in the judgment of the PO by the steering team.

      Thanks again for the post and I look forward to more in the future.

      Author's profile photo Daniel Mueller
      Daniel Mueller

      Hi Carmen

      Thanks for your Blog post.. great content and experience you share with us . I'm also involved in a bigger project with agile approach. Since many external partners are involved with different (or no) Knowledge about Agile Approach, it is quite a challenge to bring the whole Project on a level to understand the Agile working mode and convince the whole project members to get an acceptance.

      Otherwise, in a implementation project whole S/4 Hana, we have lot of dependencies in between the applications and functions. Without Integration Knowledge of Solution Architect, it will not work in such a integrated application landscape.  To make a decision on and say no, the impact need to take into account.

      In my case , we started with a waterfall methodology ( Explore) and switched to agile for the build phase. Many partners did not understood the integration model of HANA ( It is not like a apps development)

      So I created a general integration layer, valid for all the streams. The integration layer represents the overall architecture, (not technically)  how to bild up a Hana system with all the Applications.

      1. Install systems
      2. Activate Application you need
      3. Do general configuration you need ( based on Business processes)
      4. Setup organisational units
      5. Configure master data
      6. Configure business processes ( only standard without RICEFW)
      7. Develop RICEFW
      8. Combine Processes to E2E Processes and make a final integration test.

      Based on this "Layer" model, we adopt this to our Wave and Sprint planning.










      Author's profile photo Carmen Constantinescu
      Carmen Constantinescu
      Blog Post Author

      Hi Daniel and thank you for sharing your experience.

      The 8 steps that you have modelled as a "layer" for all the teams is listing the groups of solution related activities that must be performed for any S/4 Hana implementation.

      I would be very interested to find out about your experience on how these solution related activities were connected to the business requirements, in the Product Backlog.

      What was the role of the Solution Architect in the definition of the Product Backlog in your case ? How much the Product Owner had a say in the definition of the Product Backlog?

      How these solution related activities were sliced down into sprintable User Stories ?

      I'm looking forward to hearing from you and, who knows, maybe you can also start a blog !


      Author's profile photo Habib KANNOU
      Habib KANNOU

      Hello and many thanks Carmen for sharing this excellent Blog