On a SCRUM meeting the product team was debating about a feature on an API that will be consumed by mobile app. We had a mock up that showed how the screen should look like and what key elements it should contain (a "layout").
Based on this and the discussion I had with the product owner I created a prototype for an API response (HAL+JSON). It was very simple, HAL-compliant JSON that did nothing more than represent the things that were on the mockups. I did not get influenced by the future ideas that were foreseen by business people as they have tendency to change their ideas often and I decided to take the minimalistic approach. My proposal was rejected by the team and I've been outvoted 7 to 1.
The team decided to use more complex, non-semantic abstract json structure, that allows for more flexibility in arranging of the layout. The downside of that approach is we ended up with a set of uniform objects that may have null and empty properties by design. They also thought it would be nice to make A/B testing possible, yet it was based on their predictions only as we had no such requirement.
Most of the time we were debating about things that were not a part of the sprint nor mentioned on the mockups. The described problems were "what if marketing in the future will ...", "what if the business might want us to ...".
I and the product owner are experienced programmers and we've seen these kind of problems in the past. We try to follow the YAGNI and KISS principles. The rest of the team is a bit less experienced and although they know these principles, they seem not to understand them.
We agreed on their solution as the team as a whole is more important for us and we did not want to fight over something that is not that important. But I'm afraid if such thing can become a precedent for upcomming, more complicated debates? How to deal with such behaviour? Is there anything that I, as a team leader, can do better?
It's worth to mention that the product is an early-stage MVP.