Tips on Re-Development an existing product

I assume you mean recreating a copy of an existing product, in which case, you may want to consider the following questions. If I've misunderstood, then these questions may be less relevant.

• What do you hope to achieve by redeveloping the product? In other words, what would success look like?
• What do you expect to learn after the first sprint, and after each sprint thereafter?
• What are the potential decisions that can be made after each sprint, based on what is learned?
• Will this recreated product need to compete with the original one?
• Is the original product still being developed?

Currently we are thinking to re-development an existing product, is there any tips I need to know as Product owner, Thanks.

Is there technical debt to be repaid here? If so:

- is it accounted for on the Product Backlog?

- what policy will you have in place for remediating it?

- is there a Definition of Done robust enough to stop more technical debt from being accrued?

What do you hope to achieve by redeveloping the product? In other words, what would success look like?

Making the right product with a right business, as once they was start working on it, the business wasn’t clear and there is a huge gap in the process and also in the business cases. 

 

• What do you expect to learn after the first sprint, and after each sprint thereafter?
• What are the potential decisions that can be made after each sprint, based on what is learned?

I didn’t understand the Purpose of the questions , My goal in each sprint to deliver the right product without any business gaps.

• Will this recreated product need to compete with the original one?

No, it will be independent product, and the old one will not be used.

• Is the original product still being developed?

Once we start the re-development the existing one will stop development.

Most people "think" they know what their product does, however, when doing a re-build they find lots of hidden features that are now missing in the newer version (Waterfall). 

It's unlikely that someone knows all the features and all the dead features for the system. Therefore redesigning can be trickly.

I would ask the business shareholders (and users if possible) to list the features within one of the sections of the system. So break the application into smaller parts (Sales, Admin, Finance, Order etc) and focus on just that one segment/slice. Then ask the development team to do the same. This can give you lots of discussion points and PBI items to review.

Unless there is a seriously good reason to re-build, you must be careful. however, Scrum is perfect for this, as the product can be incrementally designed, tested and hopefully shipped. 

From a technical point of view, I recommend reviewing the Strangler Pattern as this fits really nicely into the Scrum way of re-building complex systems.

https://dzone.com/articles/monolith-to-microservices-using-the-strangle…

Making the right product with a right business, as once they was start working on it, the business wasn’t clear and there is a huge gap in the process and also in the business cases. 

This leads me to believe that there are a lot of lessons to be learned from the first attempt. Review how the first product was built and learn how to avoid those mistakes again. A few things I came up with from that statement alone.

• Identify your stakeholders, both internal and external.
• Use those stakeholders to identify the way the product needs to work in order for them to use it.
• Create a brand new Product Backlog with items created in cooperation with the stakeholders

Treat this as a brand new product and not a recreation of an existing one. If the first one had been right, you would not be recreating it.  So build this one right from the beginning.

Making the right product with a right business, as once they was start working on it, the business wasn’t clear and there is a huge gap in the process and also in the business cases. 

That is a very non scrum mindset.

Every sprint should be about learning as much as it is about delivering.

If you're treating the existing product as a realisation of business requirements to be mined, you're seeking to commence a waterfall project. The outcome will be you will reimplement the existing solution on a new toolset. If you don't look for opportunities to learn, the new product will have the same business gaps as the current one.