What is the difference between:
A) The details evoked & scope definitions & acceptance criteria gained from the ongoing "user story conversation" a team should have with the PO, BAs, and stakeholders during a sprint
B) Unplanned Scope Creep (which causes a story estimation to be missed, a story to not finish the sprint, etc).
More specifically, how do you evidence scope creep & estimate/schedule slip caused by A vs. B?
I have an agile team of cross-functional front- and back-end engineers, designers, QA testers. We work in a Kanban continuous pull-based flow, decoupled from a number of Scrum ceremonies like stand-ups, backlog grooming, retros, etc.
We receive project/feature documentation from the executive team defining high level business value and high level low-detail specifications of a desired project/feature.
I act as the PO (among other hats I am wearing), which means I am involved in this executive level scoping, learning the feature vision, business need, and finer business logic during this process.
Next, the team kicks off feature development and breaks this initial documentation into user stories, each story defining a MVP-type story which can deliver value on its own. The team grooms the story and comes to a common agreement. At this point, the team & PO aim to have 99.99% defined business logic, but leave the "how" open.
When development starts, the team is encouraged to continue the user story conversation to evoke finer and finer detail regarding UI, UX, and minor business logic behavior. This requires conversations with myself, our creative director for art/design direction, and our CEO for strategic product direction. Along with this conversation, development and UI exploration is underway, which generates knowledge, which in turn generates new understanding and possibly new or modified business requirements.
The problem I run into is a near infinite "internal iteration" on this user story conversation. The creative director goes into perfecting the UI/UX, the CEO goes into perfecting the business behavior of the feature, and I struggle finding a balance between delivering a MVP and delivering a feature that all stakeholders are happy with.
My current solution is to ride this fine line by breaking major departure from the initial user story into a separate user story, while allowing minor tweaks of all kinds to proceed as part of the existing user story. This approach feels OK, but I feel it might contradict agile/lean thinking. Then again, I feel that A) MVP with PO/stakeholder sign-off and B) User Story Conversation might be contradictory in their own way and that they can't both be applied at the same time.