There are not a lot of guarantees in life, but change is definitely one of them. Therefore, it is no surprise that while building products, requirements regularly change. Whether the changes are based on new discoveries from users or the market, opinions of product owners and stakeholders, or due to something entirely different, most projects will require shifts from the original “plan.”
Re-prioritize Regularly
When projects are managed using agile principles, these changes can more easily be incorporated. The earlier in the process we realize changes are coming, the better we can prepare. Contrary to waterfall, where a giant spec doc is created before the project starts and all requirements are agreed to, agile focuses on working on the highest priorities first and adjusting iteratively. These priorities are set with the Product Owner and stakeholders and help determine ahead of time what a desired MVP should resemble. Whether you are using vanilla agile, scrum, lean, kanban, etc., each methodology chooses to determine the highest priority features before each cycle of work begins.
Set smart product goals and dates
This does not mean there is not a fully thought out plan for the product. A product owner still should have created a product roadmap and may even have a release plan with tentative dates based on high level estimates from the developers, designers, and QA. This is all great. But as many of us know: business people love dates. And for good reason. They have to understand what value is being bought with the cost they are investing in building the product. Dates help to understand when something will be shippable. In addition, many times other departments will have to be involved, such as marketing or sales, so having a timeline is essential.
Where we tend to see problems is when dates are determined by the wrong people. Choosing dates based on customer demands, for instance, is a dangerous habit to get into. Especially when dates, or deadlines, are determined without having any weigh in from the technical or product side. Many times, when unrealistic dates are set, the delivery team is being set up to fail. The saying “nine women can’t have a baby in one month” comes to mind. No matter how great the team is technically, how much overtime they are willing to invest, and how wonderfully the project is being managed, some dates are just not feasible.
Determine what can be done
That being said, I would never suggest just saying “no” to a date. Instead, determine what can be delivered by the desired date. Are there features that can wait for an immediate phase two? (Assuming phase two’s ever happen 😉 ). Can priorities be shifted in a way that makes development able to move quicker? Can iterations potentially be shortened, so that features can be delivered quicker? There are many things in your project, product and process that the team can analyze to see how you can say “yes” to more.
When the priority of features change within a project, agile allows for quick adjustment. The bigger challenge is when new features are added and become priority. New features are a bad thing. But they have to be weighed against the current priorities. Removing lower priority features will help balance scope creep. From there, timelines, budgets, and burn downs need to be modified, communicated, and agreed upon. Committing to hard dates up front ties your hands to a date and not a feature set. While more people can be added to the team, and the team can work overtime (which is also a horrible long term solution with lasting side effects), many times that will not be enough. Also, all additional requirements and changes are not created equal. The best way to understand the impacts is to work directly with the product team. They can better explain the risks and roadblocks.
Keep customers’ needs ahead of your own
When new features are determined to be of higher priority, the product owner and stakeholders must agree which features will no longer be included in the initial launch. This is a hard conversation, as a lot of times, the team has already determined the features required for the minimum viable product. Much to the development team’s dismay, product features will trump technical “nice to haves” that may be able to be moved to phase two. Ultimately, the customer/end user has to be kept front and center, and anything that will impact their adoption should be a key MVP goal.
In conclusion, it is best to accept changes as they are introduced. To help this happen smoothly, communication is key. New features should be vetted against current features to see what can be pushed for phase two, especially when there are deadlines. Once these changes have been agreed upon, it is very important to make sure all teams understand the new direction the product owner has committed to. To help alleviate these problems from creeping in, it is always best to have the whole product team help set dates, so that they are realistic and attainable without having to change budget, scope (with the exception of switching priorities), or team size.
