4 ms·
It's true. But often that scope isn't properly defined. So you get a fixed timebox, a fixed "scope" (product has to be finnished) and a scope that's unclear. So
by bartimus 4y ago
It's true. But often that scope isn't properly defined. So you get a fixed timebox, a fixed "scope" (product has to be finnished) and a scope that's unclear. So first make sure the scope is properly defined. There's the current state and the desired state. There should exist a list of the business requirements that aren't covered by the current state.
Second make sure that list of business requirements is actually a list of business requirements. Often I see clients coming with lists of missing functionalities (e.g. a list with the desired functional design = waterfall). It's nice that clients come up with their suggestions on how things could be implemented. But these should not be set in stone and always come accompanied with the actual business requirements. If the business requirements are unknown the team will be unable to know if certain things might be covered in other ways. Or come up with alternative/reduced solutions to get them covered more quickly.
- pojzon 4y agoWhat you described is a waterfall. If you want to deliver quality stuff, you have to iterate fast a ask for feedback. They screwed up be ause they spent too much time on the initial phase. During that time they should have already prepared few PoCs that could transform into MVP by now.
- rblatz 4y agoYes! Thanks for calling this out I see this mistake so often.
- jacobr1 4y agoAlso customer feedback usually trumps top-down opinions even when operating in a waterfall model. I've rescued a few "ScrumFall" projects by just ignoring sunk-costs and seeing how fast you can iterate to an MVP from what you have. If you real customers that find value in the smaller scope project - it trumps the political battle around what the scope really should be and buys you credibility to adjust timelines and iterate more in the future.