We are currently setting up a scrum team to implement a product selling application. The product itself is quite complex (an insurance product) which comes in many facets, basically some mandatory and a lot of additional, optional components. So we have a lot of business rules that ensure that
a) the only valid combinations of components are provided to the customer (Product rules) and
b) all required inputs are clearly shown and only valid inputs are accepted (other Business Rules and Validation Rules).
The rules depend on the components of the product, customer specifics (age, income, health status, job, etc.) and so on.
Without Scrum, we proceeded as follows:
1) sketch the UIs with the client's expert: "customer", "offer" (which must be capable to show all product variants)
// ... to find out the UI-Design and the data model, i.e. the required attributes for all product's variants
2) get all the rules based on the before defined model for all product variants from an expert
3) implement the UIs and the rules.
As quality checks in step 3) we had typically: UIs without any function, UIs with increasing amounts of rules implemented.
Ok, now we are going to use Scrum for the first time. Next week will be the first Sprint Planning Meeting and I know the user stories are like
a) As the client sales manager I want to sell the easiest top-selling variant X from our product in the application to get much money fast.
b) As the client sales manager I want to sell the 2nd best selling variant Y from our product in the application to get a lot money fast.
c) ... guess, but we will have 10-20 of those stories and they have maximum priority.
The point is: I have no problem with this kind of user stories. They are valid slices from the users' points of view. From some point of view they are also independent.
But I fear and expect a lot of rework when we implement these stories sequentially in several sprints: In story n+1 we have to extend UI from story n, extend and modify the rules from story n.
I looks like we have just add a feature, but what we really have to do is to extend and modify the previous product version, i.e. you actually also have to modify a lot of existing rules to integrate the new stories' features.
I feel something is wrong when user stories seem to produce so much rework!
Added 2017, Jan 20th -- after reading the first anwsers Ok, I think, I understand what you all mean. I am not sure, but eventually my question was a little misleading. So let me ask a little different: Assume I have a backlog for a new product with 4 fat epics, each with say 10 User Stories. The Product Owner prioritised the epics 1, 2, and 3 for releaes in this year, epic 4 for next year. You know can go with application design A for epic 1, 2, 3, but you need another design B, if you also want to integrate epic 4. And you know refactoring from design A to design B is more expensive than starting with design B, which is a little more expensive than A. What would be the best Scrum approach here? Should there be something like a special Sprint for architecure/ design at the beginning (and from time to time again)?