Showcase is very important in agile product development. It lets the product development team project the work they have done so far in front of the stake holders or the potential end users or business users. Primarily showcase is done to take early feedback and reduce the last minute surprises. It’s also done to find out if the Product Development team is building the product right.
Why some of the show case results in too much of feedback/comments or sometimes creation of some other story cards or Change Requests? This blog article is to share my views and opinion on the same. Ideally when business analyst (BA) write down the narratives or story, they generally get it reviewed by the client. I suppose the BA do their homework before presenting the narrative to the client. So the question is even though the narratives are approved by the clients, why the showcase fails (a harsh word to use)? There could be many reasons but as per my understanding I feel there are only 2 prominent reasons.
The first reason I see is : when client actually see the developed functionality they realize that this is not what they wanted or it could have been developed better with some more enhanced functionalities. Prototypes actually help you think better and decide. And so the importance of prototyping cannot be ignored. Second reason is: when business analyst (BA) discusses the story with a bunch of developers and testers, sometimes it so happens that developers points out some technical difficulty in implementing the story. So BA (who supposedly should represents Customer) get convinced and compromises. This not only leads to the deviation from the original story but also changes the way we should implement the story. Sometimes we do this to get feedback, but most of the time this results in lot of re-work both from development and testing point of view.
So a noisy* showcase will always end up in creation of Change Requests. 🙂
* Noisy here means showcase with too much of comments/feedbacks.