Do user stories mean rework? How much is ok?

Question

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)?

Answer 1

Do user stories mean rework?

Yes.

Scrum is Agile, and Agile means you need to be able to respond to change. If you cannot handle having to rewrite code, you cannot possibly (honestly) call yourself Agile.

How much is ok?

That is up to the Product Owner, who decides based on the input from the Development Team and the customers, typically during the Planning Meeting.

To elabourate: During your Planning Meetings, the Team goes through each of the stories in the Product Backlog, starting from the highest priority and working downward. For each story, the Development Team collaboratively come up with an estimate of the relative effort they believe that story to require. The Product Owner (who represents the Product, and, by extension, the will of the customers) then decides whether to include that story, or to lower its priority (or to break it up into multiple stories, refining or rejecting the story entirely, etc.) This process continues until the Sprint is full, at which point the Planning Meeting ends and the Sprint begins.

Now, various techniques, tools, processes, etc. will have an effect on how much impact the need to rewrite code will have on the effort required on your stories - unit testing will reduce it, for example, as will CI, while poor quality or overtime will increase it, etc. In the end, though, the entire process boils down to the Development Team deciding how much effort a story will take... and the Product Owner deciding whether or not that is 'ok'.

Sidenote: You noted in your question that "we will have 10-20 of those stories and they have maximum priority." This is not allowed. In Scrum, each story must have a distinct priority. No two stories can be equal in priority, or else the Planning Meeting will not work.

Answer 2

It's perfectly valid, as long as you:

• Are able to ship each story (or a few stories together) as soon as they're ready so you can start earning money with your product.
• Or use the increments to receive feedback from (potential) users to make sure the rest of the application fits better to their needs.
• Or will be able to decide some stories will not be needed at all, because you're making enough money selling the first 15 product combinations. Based on measurements
• Or will be able to prove that further combinations will cost more to implement and maintain in the long term, and thus will not deliver them.
• Or find new or other unexpected opportunities that you may be able to deliver between some of the less important combinations.

At the same time, if your team invests in Automated tests:

• The risk of this rework is low, tests will catch issues before they are shipped
• The effort for testing will be less then when you deliver all the stories together
• The chances of finding late defects (which are much more expensive to solve) are much lower

And you'll be able to:

• prove your design and architecture choices are solid, before building all 25 product variants on top of it

There's lots of hidden value in iterating over the different variations of your product.

Answer 3

"Rework" is a term from implementation level. User story by definition exists on another level. User story is implementation-agnostic and the question literally is irrelevant.

Rework by itself is not bad. Rework which brings no value is bad. Rework which brings value when it is too late is bad.

Rework done under iterative approach (which may have user stories as its part) is still rework. But the approach enables you to select rework which brings the most value, deliver it faster and get feedback faster.

Also it is not forbidden for product owner to elaborate and share sensitive requirements (business rules) before writing stories. In fact without this knowledge it is not possible to manage stories backlog and cooperate with development during the sprint.

Answer 4

To start with, this isn't a user story, it's more of a project charter (Value Statement or Epic in some circles).

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.

A user story should be small enough to implement in a few days time and well defined enough for a developer to begin design & implementation. In the times before Agile, we called them Use Cases.

---

Anyway, to answer your question, yes. There will be "rework", but it's best to stop thinking of it as rework all together. Instead, realize that your team was going to have significant actual rework anyway. In traditional development, you'd gather requirements, implement a solution, and deliver it only to have your end user be disappointed in the result. You can either then rework it, or leave your customer dissatisfied.

With iterative development, you accept that you're unlikely to get it right the first time, so you deliver something as fast as possible. At that point you have an opportunity to find out what the requirements really are. You've gotten to your end goal faster and, because you've involved your customer in this discovery process, you have a happier client.

Remember...

• Customer Collaboration over Contract Negotiation
• Reacting to change over following a plan.
• The primary measure of progress is working software.
• We welcome changing requirements, even late in development.

Agile is a mindset, not a methodology.

Answer 5

That's just one of the reasons why the latest research is showing that agile is more expensive and takes longer than waterfall

Up to 80% of a sprint is re-work

One day, someone will wake up and say "hey - why dont we do it right first time?"