Summary: All ceremonies in Agile are important but in my opinion control over your backlog is most important.
Description: As a budding Product Owner, I would like to compare my experiences on running two projects as a proxy Product Owner. Both had challenging customer, with limited budget, but they wanted to have rich and complex functionality to be rolled out during the initial phase of the project.
We started the project with Customer A with set of agreed requirements. After the first sprint demo there was lot of feedback which was added to the backlog but the customer was adamant to have their feedback implemented immediately. In order to soothe and achieve customer delight we added all the feedback and change requests into the current sprint. This became pattern and with each demo came the new requirement, hence we deviated from the list of agreed items and it made project status go critical. Customer was then unwilling to pay for the extra time and feedback incorporated because we had lost the track of original scope, and crossed the existing timelines and finally the project collapsed.
Keeping in mind the learning from Customer A, we started a new project with customer B. We keenly listened to the customer, understood their business problems and kept evolving the backlog via continuous backlog grooming meeting. Backlog was prioritized and agreed at regular intervals with labels like Most valuable items, Good to have items, Items must have before launch.
We utilized the Sprint zero(Discovery) for technical spikes and clarifications. This enabled us to look through the vision of the product and setting up the initial ground. We then generated different versions of Release plan, with different scope, requirements and costs. Release plans were then presented and agreed with the customer. This helped us attain common understanding of the end goal of the project.
Sprint demos and other agile ceremonies were holistically played. Changes and feedback were always welcomed but ad-hoc changes were restricted inside the current sprint, making the current sprint protected. Future Sprints were proactively pre-planned, by defining the priority and by looking-ahead for the sprint scope. These helped team to concentrate on the core functionalities.
Escalations regarding sprint scope, time etc were timely raised. Current status of the project was shared at regular cadence with the customer via release burndowns, projecting the project end dates with the scope changes, keeping all stakeholders aligned with scope and timelines. Continuous backlog grooming sessions were done even at the later stage of the product along with prioritization to keep the backlog health and scope aligned with the product vision.
Our highest priority was to satisfy the customer through delivery of a Most valuable software with the required scope and timelines.