How can you manage scope creep when stakeholders request new features?

Stakeholders will always want dates and a project roadmap. The reality is that it never ever ever ends up being like that. One approach I like, is to define very high level concepts and milestones, instead of actual features for a game, because after all, creating games is an iterative process, that can't be shown in a linear project timeline most of the times. I would consider defining scope like this: Months 1-2: Prototyping. Target metrics: 20-30% D1. 30 mins playtime. If metrics are hit, we continue, otherwise, we repeat the process. Months 2-3: Early retention and early monetization: Target metrics: D1 Retention 35% Ad consumption 50% of players, and 2 ads per player. .. etc. Scope is time. Add POSSIBLE features to hit metrics

Requests for new features are common. Each situation is unique and is often dependent on the specific context. However, there are methods to discern, “what problem are we trying to solve.” 1. Ask questions to clarify. Where is the information coming from and what is the relative importance? 2. Examine proposals impartially, considering how the new feature aligns with the broader picture. Identify elements from the new feature that can be added to existing features. 3. Evaluate pros/cons. What impact will the changes have on the product, other priorities, the timeline, and the expected results? 4. Do not be afraid of change if it is better for the product but help everyone understand and align to what the new direction means.

Show them the Agile Triangle. It’s a picture. They’re smart - hopefully. They’ll get it. The Agile Triangle rewards delivering value over delivering the illusion of control. This means that the traditional way of creating a game assumes you can lock down scope, cost, and schedule at the beginning. Of course that’s not true. The focus should be on building a fun (valuable) experience for your players that just works and performs well (quality). The constraints of cost, schedule, and scope are not locked and are the variable sliders that allow the team to build the best game possible. If stakeholders demand additional features then something’s got to give, either scope, cost, deadline, value, or quality. Stakeholders “fix” = Crunch ??

Scope creeping frequency hinges on clarity of vision but often, the market changes and one has to adapt. Start with a yes, always, and then ask the most important question - Why? Why is this feature so detrimental and dig deep! Start with why and in doing so, we’ve often found solutions in the existing design that can alleviate concerns. That being said, sometimes its implementation can require a complete overhaul. This leads me to the second question - what is the impact? The definition varies from user satisfaction, revenue variance or functional relevance to development costs. All of these have to be placed in careful consideration before deciding. Start with a yes. Don’t be afraid of change and then ask the meaningful questions.

A important word in any developers vocabulary should be no!??. The temptation is to try to accommodate and say yes to everything, especially a key stakeholder. But no could be the right thing to say for the project and team. Before saying no however.. ? Be clear in your reasons and justifications. Keep emotions out of this and go in armed with as much info as you can behind the decision. ?Be pragmatic and emphatic, you will want to also understand why it's been requested and how features you are developing ?A no can lead to a middle ground or compromise, but it's important to be honest and put your informed points forward.

Have a roadmap. If you don’t then it won’t be clear what effect adding scope will have. Change is inevitable. Sometimes it is the only way to hit your goals. The question is what you’re willing to delay or cut in order to make it happen. To your stakeholders, you want to provide clear consequences for their request so they can make an informed decision. Generally I find it best to suggest multiple options with a top recommendation, but it depends on your audience. Clearly show your time/cost estimates for the request, what changes you had to make to other parts of the project to make it happen, and be sure you get final approval before getting started.