Some product owners, managers and organizations have a believe that for it to be okay to show someone the product being developed it has to be polished, shiny and with all the expected features in place. Every occasion where the product is presented is a risk of being criticized, and if the product is in an early stage of development, they are not yet ready for critique.
“The team should be able to deliver more than this by now… Why aren’t they more productive? Let’s add more backlog items to the sprint backlog to make sure everyone is working with something and is kept busy!”
If planning won’t bring predictability, or an accurate answer to the question “When will it be Done?” in a software project… I guess there’s no need to create estimates either, right?
Back in the days when everyone was doing big waterfall projects, both in software and other fields, we used to have an “Analyze”-phase. Today we do barley dare to call a project waterfall (because no one want to be associated with something so out-of-fashion as waterfall-projects).
All development and changes to a product comes associated with risk. The risk of building the wrong thing, the risk of building features that does not speak to the users, the risk of introducing bugs. The list goes on and on!
What is a “potentially releasable product increment”, really? Last year I worked as Scrum Master in a team that delivered software for multiple target platforms. One of the products was a mobile application. The mobile application was target for multiple markets and regions and needed multi-lingual support. One of the features in the application was to switch between different languages inside of the application (the app runs on a device available to a range of people with possibly different primary native language).