Product review extremely useless for customers and stakeholders
I'm insisting on having product reviews at the end of a sprint, but actually, it will be very useless for potential customers and stakeholders alike:
- we have very detailed clickable mockups.
- Business stakeholders are not interested in "viewing" a piece of software half-implemented that looks like the mockup but has fewer functionalities. They want to know when it's finished. They have feedbacks, sure, but on the mockup.
- potential customers are actually involved in the design of the products, but there is no way they could meaningfully use it unless we are 80-90% done with respect to the mockup. So also for them, all the interaction happens in the mockup.
I would understand a product review when we will be ahead of mockups with development and when mockup will be used to implement a story.
But now our product development cycle looks like this:
- mockup -- feedback -- user story -- implementation -- mockup change -- re-implementation etc...
rather than
- user story -- mockup -- implementation -- feedback from using product -- new user story etc...
I feel that the above lifecycle will start when we will have a working product, let's call it MVP, with customers really using it, rather than potential users speculating on product possibilities...
Now it's a mess
I feel that the above lifecycle will start when we will have a working product, let's call it MVP, with customers really using it, rather than potential users speculating on product possibilities...
Start with a Definition of Done. What's the smallest thing you could build which would then be Done?
Using that MVP, encourage potential users to speculate on the possibilities.
Hi Ab!
- Why should the Sprint Review be used as a demo?
- Why don't you use it to inspect the current state of the increment and the product with the stakeholders?
- Why don't you talk for instance about the results that you have obtained with the tests that the team has performed with the users or the new risks and difficulties that the team have found?
- Why don't you employ the event to inspect the current strategy and adapt the Product Backlog in accordance with what has been discovered during the iteration?
- If there are meetings where these topics are approached... Is it not that meeting the real Sprint Review?
Hope this questions could be of any help in order to reflect about the situation based on your context, Ab!
- mockup -- feedback -- user story -- implementation -- mockup change -- re-implementation etc...
Just to clarify, you create a mock up, get feedback, build something, update the mockup to look like what you built, then repeat?
That seems like a waste of time. You have created a mockup as a general guideline. Start building a product. Use the Sprint Review to update the items in the Product Backlog to reflect the input from the users and use the mockup for reference but not as the guiding source. You can show the stakeholders what you have built and then switch to the mockup to show what you are expecting to do for the next sprint. Update the Product Backlog appropriately based upon any feedback given by the stakeholders.
That is my suggestion. In agile, a basis premise is the empirical loop of work, inspect, adapt. This applies to more than just the content of the Product Backlog. This applies to the way work is done as well. You also want to make sure that everything done is effective and efficient in order to be able to move rapidly. Try experiments that can improve the work process.