# How I handle delivery when scope keeps growing Source: https://manaienko.com/how-i-work/delivery-when-scope-stops-being-honest/ Author: Artem Manaienko At ASKfm, we spent about six months on a two-month MVP. The feature worked, but I still see the delivery as a failure. We kept rebuilding while the requirements changed. I should have forced the scope and date conversation much earlier. ## My principles 03 operating rules 1. [01 Revisit the estimate when the work changes](#practice-delivery-when-scope-stops-being-honest-principle-1) 2. [02 Be clear about what makes a release ready](#practice-delivery-when-scope-stops-being-honest-principle-2) 3. [03 Own the failure even when the feature succeeds](#practice-delivery-when-scope-stops-being-honest-principle-3) ### Revisit the estimate when the work changes If new requirements mean rebuilding part of the solution, I want that cost discussed immediately. Product and engineering need to decide what to cut or postpone, or agree to move the date. The people accountable for the outcome need to make the scope, date and quality trade-off. ### Be clear about what makes a release ready At ASKfm, I moved us towards releases built around one main feature. Related fixes could ship with it, but unrelated work could not keep becoming another reason we were unable to release. ### Own the failure even when the feature succeeds A good product result is welcome. I still need to look at what the delivery cost the team and where I should have intervened sooner. In this case, we let changing requirements turn into months of rework. ## What went wrong and what I changed 02 cases ### Six months for a two-month MVP ASKfm · 2016-2021 **Situation:** We planned a feature for roughly two months. Requirements changed after the engineers had designed the architecture, and parts had to be rebuilt. As the work grew, product and engineering started blaming each other for the delays. **What I did:** - Made it clear that we could not keep expanding the work and hold engineering to the original date. - Kept working towards a complete release. We chose to accept the delay rather than ship a degraded feature or abandon the work already done. - Used the experience to change how we defined releases and handled changes to their scope. **Outcome:** We shipped after about six months and the feature did well. I still think we handled the delivery badly. We should have stopped to re-estimate and agree on scope whenever the requirements invalidated the design. We did not do that early enough. ### Giving each release a clear scope ASKfm · 2016-2021 **Situation:** We used to pick a date and put a bundle of work into the release. Then more work arrived, dependencies appeared and the date moved again. I worked with product and engineering leads to change that. **What I did:** - Made one main feature the purpose of each release, with a clear condition for when it was ready. - Allowed compatible fixes and smaller changes alongside it, without making every item a blocker. - Made changes to the main feature trigger re-estimation and an explicit discussion of the impact on delivery. **Outcome:** We had a clearer way to agree on scope and dates. Delays still happened, especially when the main feature was difficult. The delay became an explicit decision for the people making the trade-off, instead of quietly moving through the schedule. I did not measure lead time or release frequency before the change, so I cannot put a number on the improvement. I would establish that baseline next time. Release model Before ### A date and a growing list - Pick a date and bundle work into the release. - Keep adding work that has to ship with it. - Move the date as the scope grows. After ### One main feature - Agree on the main feature and what makes it ready. - Include compatible fixes without adding blockers. - Re-estimate when the main feature changes.