We’re enhancing community stars, and the scope of a particular feature enhancement has slightly crept. And we’re very pleased with the scope creep. It’s gonna be great and opens up lots of cool things!
Traditionally, scope creep is mostly viewed with a negative lens, so I’m curious to know:
When has scope creep been good scope creep? What happened, and what unexpected impact did it have? How often do you encourage/welcome a bit of scope creep?
After seeing so many stars of MoT, all I can say is I want to be a moon of MoTAVERSE 
… be different always
I am wondering if scope creep is more of a waterfall thing. I feel like if there is a strong agile approach then scope changes can be discussed, understood and agreed. If you aren’t doing that it isn’t agile.
Any “can you just do this” or this “needs to take priority” can be quickly understood and agile practices help to decide what impact it has on the sprint or delivery in general based on estimation.
Having said that, there is often a change of business priority where someone outside of the agile delivery insists that all the things must be delivered now. Which at least where I am currently ends up as a dropping of tech debt fixes, potentially trimming other tickets from the release as we go and recognise the lower priority tickets aren’t going to make it. Which is our own kind of agile in a way.
So, does scope creep indicate a delivery process that isn’t agile or communications that are top down and unchallenged?
Am also happy to say that I create “scope creep” by asking good questions as all good testers do 
And make it clear when a small code change will create a much larger test effort.