Generally everyone likes to avoid rework. There are 2 key reasons team why people like to avoid rework:
There is a cost associated with rework - since you have to spend additional effort to correct whatever you did first. Sometimes you might have done things around this piece of work which might also need to revisited if you have to change something. A good physical example to understand this - If you had to break a wall in a house, it would incur more cost than just breaking the wall and rebuilding it because you would also have to redo some electrical work, flooring work and what not.
The second cost of rework is more psychological - you don't want to, or rather, there is a mental block to revisiting things that you thought was done. So there is that resistance to change, which can take time and effort to overcome.
That said, in the product development world, rework is unavoidable at times. This is because of two key reasons:
You don't know for sure what is going to work with customers
Sometimes the way things are developed is different from the way the customer/ product manager envisaged it
In both these scenarios you would need to rework.
The key thing to keep in mind about rework:
Rework later in the development cycle is more expensive than rework earlier on.
Given this, the way your product development sprints are setup should be to get maximum feedback from critical external and internal stakeholders as early as possible. So your mantra should be:
Feedback Early, Feedback Often
A few techniques you could adopt to achieve this:
Developing wireframes and click through prototypes to get feedback
End of sprint demos to get feedback from critical stakeholders
Prioritising user stories to be able to get your riskiest pieces out first (in a meaningful way) so that you can get critical feedback
That said, customer preferences and industry landscapes are constantly changing. What worked with customers 6 months back may not work anymore. So you have to keep your mind open to changing things as you go along.
Caution: When you make changes, in order to do the change the well, you will often have to make changes to other parts of the product as well. But due to time/ cost pressures you will end up taking short cuts. Going with the earlier breaking the wall example, you may choose to avoid/ reduce the electrical rework - You hang a bulb instead of having a light fixture.
And that leads to Technical Debt!
Technical Debt is a topic which deserves a couple of dedicates posts!!! 😃
If you are facing challenges with lot of rework, give me a shout, I may be able to help!