“What if the customer clicks on this button, sees the popup, types some text, then cancels, and later comes back to the popup — do we preserve the previously typed text?”
This is a typical conversation that happens during product / design / technical discussion on software engineering teams. Inadvertently, the answer is an enthusiastic “yes”. Everyone wants to deliver an awesome product that’s thought out through and through. And therein lies the danger — we get carried away and blow up the scope of work.
According to Mary Poppendieck’s “Leading Lean Software Development”, 60% of released features are never used by end users. Extensive user research, user interviewing, and such helps to narrow things down, however it’s an imprecise science. Users will typically ask for everything (because why wouldn’t you), but they can’t tell us what’s a must have vs. a nice to have. They may genuinely believe that they need a certain feature only to never use it when it comes out.
For many businesses it’s more important to deliver a core set of functionality and move on than to spend time on fluffy features and questionable edge cases that might never be used. It’s also good to remember that if we end up missing some needed feature we can always add it later.
In project management there is the holy trinity of scope, time, and quality and we can only choose two out of the three. Cutting scope is an underused technique that needs to be talked about more. Cutting quality is not a good idea (modern users expect top notch products) and so is making the team work consistent overtime (lest we want to lose team productivity and potentially the team itself).
It frequently seems impossible to cut scope but if we really put our mind to it, we can find a few minor features or edge-cases that will shave 5–15% off of scope. Done consistently this will increase the average team productivity and allow us to kick out more projects. Moreover, we can timebox our projects, which will let us deliver all (or almost all) of the important, high visibility features in our yearly roadmap.
project structuring
Given the unpredictable nature of software engineering, how do we know when and what scope to cut? Maybe we can fit everything into the given project’s timeline? The truth is that we do not know upfront.
As we start working on a project, we need to first deliver the must have features. As we get closer to the end of the timebox, we can discuss the remaining features and make an informed decision on which ones we are able and want to finish and which ones we can drop.
There is a wealth of information on this technique available online, known as vertical slicing in Agile circles.
