Tests without code knowledge are waste

I start with an outrageous claim: "Software tests made without knowledge of the code are waste."

Now, let me back that claim up with an example - a calculator applet which you can actually use:

Calculator

0

Have fun, play around with this little applet ... it works if your JS is enabled!

Now let us create a test strategy for this applet:

Black Box test strategy

Let's discuss how you would test this, by going into the list of features this applet offers:

• Basic maths: Addition, Subtraction, Multiplication, Division
• Parentheses and nested parentheses
• Comparisons: Less, Equal, Greater ...
• Advanced maths: Exponents, Square Root, Logarithm, Maximum, Minimum, Rounding (prefixed by "Math.")
• Trigonometry: Sinus, Cosinus, Tangens, Arc-Functions (also prefixed)
• Variables: defining, referencing, modifying
• Nested functions: combining any set of aforementioned functionality
• And a few more ...

Wow - I'm sure you can already see where our test case catalogue is going with minimal coverage, and we haven't even considered edge cases or negative tests yet!

How many things could go wrong in this thing? Twenty, thirty? Fifty? A thousand?

How many tests would provide an appropriate test coverage? Five, ten, a hundred?

How much effort is required for all this testing? 

Would it shock you if I said ...

All those tests are a waste of time!

Frankly speaking, I would test this entire thing with a single test case, because everything beyond that is just waste. 

I am confident that I can do that because I know the code:

  <div class="row">
	<div class="card"
             style="margin-top:1rem;
                        margin-left:2rem;
                        margin-right:2rem; width: 18rem;
                        box-shadow: 4px 4px 4px 1px rgba(0, 0, 0, 0.2);">
	  <b class="card-header text-center bg-primary text-light">
            Calculator</b>
	  <div class="card-body">
	  	<textarea class="form-control"
                          id="calc_input"
                          rows="1" cols="20"
                          style="text-align: right;"
		          oninput="output.innerHTML = eval(this.value)"
                          ></textarea>
	  </div>
	  <div class="card-footer text-right">
		  <b id="output">0</b>
	  </div>
	</div>
  </div>
  

Yes, you see this right. The entire code is just look-and-feel. There is only a single executable statement: "eval(this.value)", so we don't have a truckload of branch, path, line, statement coverage and whatnotever that we need to cover:
All relevant failure opportunities are already covered by JavaScript's own tests for its own eval() function, so why would we want to test it again? 

The actual failure scenarios

Seriously, this code has only the following opportunities for failure:

• Javascript not working (in this case, no test case will run anyways)
• Accidentally renaming the "output" field (in this case, all tests will fail anyways)
• User Input error (not processed)
• Users not knowing how to use certain functions
  (which is a UX issue ... but how relevant?)

Without knowing the code, I need to test an entire catalogue of test cases.

Knowing and understanding the code, I would  reduce the entire test to a single Gherkin spec:

The only relevant test

Given: I see the calculator

When: I type "1+0".

Then: I see "1" as computation result.

So why wouldn't we want to test anything else?
Because: the way the code is written, if this test passes, then all other tests we could think of would also pass.

But why not write further tests?

A classical BDD/TDD approach would mandate us to incrementally define all application behaviours, create a failing test for each, then add passing code, then refactor the application. 

If we would do this poorly, we would really end up creating hundreds of tests and writing explicit code to pass each of them - and that's actually a problem with incremental design unaware of the big picture!

The point is that we wrote the minimum required code to meet the specified functionality right from the start: code that has only a single failure opportunity (not being executed) - and after having this code in place, there's no way we can write another failing test that meets the feature specifications!

And that's why a close discussion between testers and developers is essential in figuring out which tests are worthwhile and which aren't.

Stories that aren't

 Let's take a look at the "User Story Template" (also known as: Connextra Template, by origin) - "As a ... I want ... so that ..." - straightforward enough. It's common in the "Agile" space, and many inexperienced Scrum Masters and coaches learn that teams should formulate their work like this.

The result?

Formally it's correct. It's a "user story" based on the template. 

Now, what's wrong with it? About everything.

Let's leave aside for a minute the fact that this story is as much of an antipattern for "INVEST" as it could be, and focus instead on the use of the template:

1. The "user" isn't a "user". 

If we start calling developers "user", then next thing we know, testers, analysts, and project managers are also "users". It becomes a hollow, meaningless term.

A "user" is someone who actually uses the end product. 

Like ... a Candy Crush user is, for example: the "mother of a small kid who only has 5 minutes before the kids will cry again."

(Of course, developers can be users as well. But that would require them to actually use the product, in which case they wouldn't be a developer, but ... for example, a "mother-of two who sits in front of computer screens all day ..." - if that's your demographic!)

2. The want is a means, not an end

"Wants" should be something that this specific user wants to have and would be willing to use our product for, like "simple and easy fun". No user ever wants a Customer_ref_ID. Maybe they need it to identify themselves, but ... can you name anyone who wants to use a product because it has a Customer_ref_ID? 

Could you imagine running a marketing campaign with the slogan, "We have a Customer_ref_ID" - if not, then you're probably not addressing anything someone wants. 

Take it as a lithmus test for formulating "wants":

If you would feel weird to see it on a billboard on the way to work - it's probably not a proper "want".

 

3. The reason is self-serving and circular.

In more abstract terms, the reason is "so that I have it." - it doesn't explain which problems it solves.  It adds no information. It doesn't help us verify whether we're adding value to the product, and it doesn't help us verify whether we actually need it. It's a fake reason.

Let's, for argument's sake, assume that both the user and the want were valid: we still don't know why you want to refer to the customer by ID, and how that is better than what you're currently doing.

A good reason statement shouldn't repeat the "want", but explain why the "want" is relevant, which problem we're solving, how the world is better after the need is met.

Good reasons invite developers to understand why the user has an unmet need.

The problem of Proxy Users

User Stories - what's a user story, what's even a user? And: Why is that important?

The definition of a "user"

User - a person who uses or operates something.
Sources: Oxford, Google

A "person" can be both an individual or a legal entity.
The specific mention of the term "person" is quite important. We will get back to that later.

There are other definitions out there, also - that have a different emphasis:

User - a person or thing that uses.
Sources: Dictionary.com, Collins Dictionary

This definition opens a different way of thinking - that "things" (physical and/or virtual objects) can be users s well.

Types of "users"

There are various types of users.

To explain them, let's take a look at this scenario:

Scenario:
A person has bank account without any deposit money.
The problem? Checks bounce on this empty account.

Here are some core types of potential users and their problems in this scenario:

Category	Description	Example
End user (Customer)	Someone whose problem is being addressed.	Bank client: Bouncing checks means there is unpaid debt.
Service Provider	Anyone who provides a service using the product.	Bank: May get calls from both their customer and the people their customer gave checks to, asking what's wrong.
Intermediary	Representative of the Service Provider towards the person whose problem is being addressed.	Bank clerk: The person at the counter, answering on behalf of the bank what's happening.
Proxy	Representative of the person whose problem is being addresed.	Bank account: A virtual entity that acts as a proxy on behalf of the customer both towards the bank and the customer's transaction partners.
Delegate	Acting on behalf of the person whose problem is addressed.	Accountant: Responsible for balancing the customer's finances.
Administrator	Responsible that the product or service can be used correctly.	Bank IT: Checks need to be rejected rather than processed.

Why is the discrimination between those "users" important?

Know your Users!

Users define success

For example, if you develop in-house business support software, your user is often a single company, which means you'll have an entirely different way of measuring success than if your user is a Customer on the free market (of whom there could potentially be a couple billion). And the value of your product may depend on two categories of users: the Service Provider, whose balance sheet ultimately determines whether you are building the right product - and the Intermediaries, whose use of the product determines whether you are building the product right.

Users want their problem solved

Especially in large corporations, it's easy to lose sight of what the product actually is - and who the users actually are. By solving the wrong user's problems, you run the risk of local optimization - potentially damaging the interests of your real users in the process!

For example, look at this rather typical "User Story":

As a Security Specialist, I want people to choose difficult passwords and short password renewal cycles, so that accounts stay secure.

Then, think of yourself: How would you like it if the engineering team of your favorite app would spend a month to create password rules so complex that you need a PhD in Cryptography just to be able to determine what's a valid password - and then being forced to choose a new, different password every time you log in!

Solving the right problem

Intermediaries, proxies and administrators pose requests on systems, and while their requests are undoubtedly important, they all don't help you to solve the right problem!

Compare, for example, the following two user stories:

As a bank clerk, I want to be able to see the customer's balance with a single click.

As a bank, I want to know why I'm losing customers!

And now, let's add another user story:

As a bank account, I want to let my customer know when I have no money!

Do you see the difference between those three stories?

Users who have no financial stake

The first story may have sprung up from a conversation with a real intermediary user, and it's fairly easy to know whether you are solving this problem. However, it's almost entirely disconnected from the real user's (the customer's or the bank's) problem.
Unless it just by happenchance occurs that seeing customer balance also addresses the second problem, there's a good chance that spending time with the concerns of intermediaries derails the team from relevant business objectives.

Users that don't have a voice

The second story is an existence-threatening problem. Yet the "bank" as the legal entity that gives employment to the engineering team, has no face or voice. Its true voice may be hidden behind layers of management and bureaucracy. It may be too far away from the engineers to give it relevance and too abstract to be worth touching.

Proxies have no real needs

The third story is all too common in large enterprises: Components, proxies - even API's become "users" - assuming that if we service them, we are solving a relevant problem!

There are no proxy problems

Here's an uncomfortable truth: the proxy has no problem.
It's never the proxies' problem - it's ultimately, a customer or provider problem.

Only when real users (end users and/or providers) interact in a way that requires interacting on a path that crosses the proxy, is there a real problem. And there are two ways of solving this problem: either helping the proxy to do their job better - or to eliminate the proxy's part of the process altogether.

Hidden assumptions

There are always hidden assumptions in proxy stories:

1. The voice of the proxy echoes the voice of the unheard real user
2. The proxy is on the critical path of transactions 
3. The proxy is the constraint to the performance of the system
4. A dependency on the proxy is inevitable
5. Solving the proxy's problem is the best solution to the real probem

By accepting the "story of the proxy", which most agile teams do with little pushback or thought, we run a massive danger of sub-optimizing a solution, and limit the solution space. While this can be valid in many cases to provide focus, this begs the question: When, if not during refinement or planning, does the team spend time to think of which solution is the best to solve the most pressing problem?

Working the Constraint

The reason why I harp so strongly on the point of "proxies" and "intermediaries" versus "real users" - is that while they are on the road to creating a higher-performing system, it's nowhere automatic that improving upon their bidding improves the performance of the system.

Theory of Constraints teaches us that:

1. Optimization outside the Constraint is - at best - ineffective.
2. Time spent optimizing outside the Constraint is Waste.
3. To work on the Constraint, you need to know how to optimize it.
4. When the Constraint is operating at its capacity - elevate it!

Here's what happens when you listen to the voices of Intermediaries or Proxies as if they were the real users:

1. You start to forget who the Real User is.
2. You remain oblivious of how the changes you are making affect overall performance.
3. You don't know if you're working the Constraint or somewhere else.
4. You may institute a new Constraint on the Critical Path, worsening the system.
5. You will miss solutions that elevate the constraint, especially if the constraint is of higher order.

Summary

It's not forbidden to have "proxies". It's just dangerous. 

To avoid the most common pitfalls, start asking:

• Do we understand the real customer behind the problem we are solving?
• Is the solution on the critical path to success?
• Are we working the Constraint?

If you can't answer these questions with a clear and resounding "Yes", you're definitely in dangerous territory - and if you can answer any them with a clear "No", you may want to reconsider implementing this story to begin with!

The problem isn't as much who your user is - it's that "fake users" make you lose sight of what value is and how to create it!

User Story Writing - what does that mean?

I keep hearing the question "How to write good/better user stories?". A quick search on Google reveals over 25 million hits, with the first page linking to Scrum gurus such as Mike Cohn and Roman Pichler, giving examples of "good user stories" and guidelines for writing them.

Let's dig deeper. You want to write better user stories? What does the term "user story" even mean?

"I don't think it means ..." courtesy of memegenerator.net

The Connextra template

As a <ROLE> I want <FEATURE> so that <REASON>

Some guys at Connextra figured out in 2001 that a good way of formulating user stories is with their template. It helped them solve their problem and now people make that a (near) essential part of Scrum.
An entire industry has been created helping Product Owners "write better user stories" based on this template. There are many good tips around, including clarity of reason, specific acceptance criteria, separation of concerns and many others. All of them miss the point. The Connextra template is an "agile template for writing requirements". Using that template will not result in a "User Story".

So, what's a user story?

As heretical as this may sound: can you imagine a user telling a story to the developers?
Someone has a problem or a need and talks about it. We decide to create software to solve this problem.

What's the PO's role in that?

The PO has the main responsibility of deciding which item in the backlog is the most valuable and therefore, should be delivered first. For this, it's a good idea to understand what the user's problem is, how big it is - and how much value the user gets from having it solved. This means you need to listen to the user and ask questions helping in the prioritization process. 

It's OK to act as a mouthpiece for the user in cases where users don't have a voice.

In other cases, the PO has the responsibility of ensuring that developers get first-hand information and a thorough understanding of the problem.

What's the team's role in that?

In Japan, there is a philosophy that it's the student's responsibility to understand their teacher. In western circles, students blame their teacher when they can't understand their teacher. Let's just say that a blame culture helps nobody - and that users often don't understand why they have the problem they are facing.

So, the team has the responsibility of figuring out what the user means. And there is no better way of figuring that out than by interacting and discussing with the very person who is concerned.

Rather than point fingers at the PO for requesting better stories, the team should learn to understand their users. 

Asking questions is a plausible way of learning. Creating common models is another. Blaming leads nowhere.

Experiences?

When I work as Product Owner, I'm not stuffing information into computer-aided ticket systems. And I'm not "writing user stories" at all. I create doodles. Every story card I create is a doodle. And when we get around to it, the first question my team asks is: "What do you mean with this one?" 

That's where the discussion starts. It ends when we're all on the same page. 

Take-Away

If you want to write requirement specifications, please do so. Just don't call them "user stories".

If you want to work with user stories, try telling stories and asking questions.

Three types of Customers

As a Product Owner and/or member of an agile team, you might be challenged with the concept of "customer value". Some people consider that only things which are useful to those who are end users of the product have real value. However, that falls short of what a customer is, so here is an overview of which groups of customers you must consider.

Primary Customers

Also known as "end users". The people who actively use your product until the end of the product's lifecycle. If we consider a Teddy bear, that might be the kid who actually plays with it.
This group of customers is typically the easiest to please, because you can directly study their behaviours.
A Product Owner should understand their Primary Customers to make a great product.

Based on the Kano Model, you can please them by triggering their "Excitement".

Secondary Customers

Also known as "Buyers". They are the ones making the purchasing decision. For some products, they might be "users", for others - not. If we consider the Teddy bear, that might be the parents or relatives who wants to buy a present for a child.
This group of customers may not even understand what incites the Primary customers and may even have conflicting interests with them.
A Product Owner must be aware of the Secondary Customers, because they determine the financial success of the product.

Based on the Kano Model, they typically look at "Performance" criteria and try to find the best value.

Indirect Customers

Also known as "Regulators". They might neither buy nor use your specific product, but they still want some say. If they actually get in touch with your product, that may be because of a dual role. If we consider the Teddy bear, that could be an activist group asking for a statement that you pay Fair Wages and provide Safe Working Conditions - it could also be the government demanding the teddy to be non-flammable and non-toxic.

This group of customers is impossible to please and will not generate a cent of revenue. The best thing you can do is not to displease them or draw their attention towards you. Keep them satisfied with minimal cost and effort.

As Product Owner, you must understand the demands of your Indirect Customers, because if you don't - they'll kick your product off the market. The hardest part may be not diluting your Product Vision in doing so.
Indirect customers are the worst nightmare of every product owner, because they will add as many non-value adding, potentially counterproductive requirements as possible into even the simplest product.

Based on the Kano Model, they require "Hygiene" criteria.

Summary

You must be aware of all customer groups. Never lose sight of any of these groups. Invest sufficient time to understand them. Do what is necessary to make your product positive towards their needs and demands.

Suggestion: Do you want to make these explicit in your Plannings?

Story slicing 101

A repeating theme in agile transformations is: "Our stories are too large, and we can only deliver all or nothing - we have no idea how to slice them". The consequences? Teams can only do few, but large stories, variation and failure probability is high - predictability and flexibility are low. None of these are desirable from a business perspective - regardless of agility. Story slicing solves this.

Since we will be dealing with fairly abstract concepts, let us create a specific example to make the subject more tangible. Let us start with the "too big" story:

As a user of the platform, I want to have a response time of less than 2 seconds, so that I can spend more time actually making progress.

This is a typical case of nonfunctional requirement, phrased as a user story with clear success condition and clear indication of business value. Unfortunately, for large systems, this pretty much means rewriting the entire code base - there is no way to get this done in a few days!

Step 1 - Start asking questions

The above story leaves plenty of room for interpretation. The first misunderstanding is that "We have to do everything, otherwise it might not work". Teams end up creating seemingly endless to-Do lists for changes that all need to be made. But they don't really ask questions.
A good way is to break up the team in a Refinement session and let them actually build a model around the story to help them discover questions, independently.
Here is what the team might come up with:

Which type of users do we have?
Do admins have the same needs as application users?
Does it really hurt if user creation takes a bit longer?
Which function actually takes the longest?
Is 2.1 seconds a problem?
We could make transactions faster by splitting into multiple minor steps, but that has more clicks - would the users accept that?

Regardless of what questions come up, what you need is that these questions are written down explicitly, not a detailed discussion to answer these questions (yet).

Step 2 - Bring the questions together

Different sub-groups will probably discover different questions. There is no "right" or "wrong" at this time, only different models, resulting in different questions. All questions are good, because they reveal how people think. By having each group bring their questions to the board, we can start to cluster questions. Most likely we will have more than one cluster.
For example:

Users and their needs
Function specific boundaries
Worst-case scenarios

What you need now is not the similarities within the clusters, but the differences between the clusters.

Step 3 - Slice based on clusters

Slicing is best done across differences, but keep real user value in mind. None claim to solve the entire problem, all will contribute a meaningful partial solution. At the moment, let us "forget" about the overall problem we have and specifically focus on partial delivery.
Here are examples for extract user-relevant, deliverable stories from the basic story:

As a new user, I want to create a new account in less than 2 seconds.
As admin, I want to wipe a user account in less than 2 seconds.
As transaction user, I want to complete a transaction in the system in less than 2 seconds.

These stories are still quite different in size, but they are much easier to handle than the entire block. After we are "Done" on the first two stories, there is still a large amount of work to be done - but also a tangible result. Some of these stories might be discarded immediately, because the team realizes that this specific need is already met.

Step 4 - Drill in, Rinse + Repeat

Looking at our example, most of the work will probably be in the third sub-story. We can drill into this sub-story in exactly the same way we drilled into our initial story. Drill-in can be channeled by moderating the team to look for specific aspects.

Here is a small list of aspects to look for:

• Workflow: Steps, user goals, scenarios
• Transactions: activities, operations (CRUD)
• Users: personae (user types), roles, responsibilities
• Technology: configuration, context, data streams (& interfaces)
• Data: content, types, subsets

With this list, you could instruct one group to look for workflow aspects and another group might examine data.

Here is an example of what the "data" group might come up with:

• 60 second timeout when the database is down.
• Stuck in a "Waiting" dialog when the Internet connection is unstable.
• Mass update speed is proportional to amount of updates.

Step 5 - Verify & Engage

Depending on how far you take this, you can slice down any large topic to as many small topics as needed until the team arrives at the following two conclusions:

1. We have discovered relevant areas for change
2. We can resolve a few stories in a fairly short amount of time

Put the most important, workable stories high in your backlog, preferrably starting with the first stories right in the next sprint - and sort the remaining relevant items into the backlog at an appropriate place. If you want to, you can keep the "master story" in the product backlog, but it's priority will be lower than that of the lowest identified story.

After all known stories are closed, the master story will pop up again - at that time, the first question is: "Do we still have a relevant problem?"

Conclusion

World hunger stories are common. The most common problem teams encounter is that they dive into the solution space before working on the story definition. However, since the story with it's Acceptance Criteria defines "success", it is most important to have a realistic goal in mind. Otherwise, there is no way to succeed.
The next time you encounter a backlog item that is "too large to do in a Sprint", try asking tough questions and slicing along the differences between the questions.

To estimate or not to estimate - #noestimates by slicing

At the risk of stating something that is already obvious - "#noestimates" does not mean "We don't have any idea what we're building or how much it costs". It means we have simplified the process to a point where risk and reward are in a sound correlation.
There are many ways to reach a state where estimates are no longer relevant. Here, we will discuss Backlog Slicing and its effect on estimation.

One way to remove the need for estimation is to slice deliverables into packages no bigger than 1 single day: At worst, you have lost 1 day and learned that in 1 day.

When you can do this slicing for any given backlog item within a couple minutes, it becomes completely irrelevant whether the slice is actually 1 minute or 8 hours, since the Law of Big Numbers starts to kick in at some point and it becomes fair to say that a deliverable is about 4 hours.

So, even with #noestimates we actually do have an estimate, but we don't bother going through all of the items individually, attaching a "4 hour, could be more or less" label to each and every one of them.

With this information, we can also predict cost and duration:
How many slices do we get out of a "requirement"? 1, 20, 1000? How many of them are really needed?

 Then we optimize: Can we deliver the bulk of the value by doing only a couple of them?

 Lastly, we can quickly observe and act: Do we consistently deliver an about even amount of slices per week? Does the number increase or decrease? Are there any significant outliers that clog the pipeline?
By observing the answer to this question, we imply data without actually measuring it:
As long as the consistent flow of delivery is there and there are no outliers, there is no problem.
On the other hand, when we seem clogged or bogged down, we realize this immediately, because we're not delivering any more.

 This becomes visible and can be fixed within a couple of days, so we can go without a company-wide measuring system that may tell us the obvious by the time the team is already working on a solution - or even worse, waste precious development time by holding the team accountable to solve a problem that we can't influence.


 Summary
#noEstimates is not equal to abolishing good business practice due to negligence or inability.
 Much rather, #noEstimates is a sensible step of evolution for developers who have mastered their technical domain, whose Product Owner is crystal clear on business value and priorities - and for  people with a very rigorous and keen Continuous Improvement mindset.

 A team avoiding Estimates without these three aspects in place may act haphazard.

So, #noEstimates is effectively "Implicit Estimates without explicit estimation overhead".

Slicing and dicing user stories

To really understand the effect that the Product Owner has on the success of Agile development, it is vital to understand the art of creating good user stories to deliver results.

As was mentioned in a previous post, a poorly chosen user story will make it tough for the team to deliver, wasting time and potentially effort with poor control over the investment. On the other hand, a well chosen user story will support the early delivery of valuable results.

The creation of good user stories depends on a technique called "Slicing", i.e. preparing user stories in a fashion that they become immediately useful once completed.

Horizontal slicing is bad

A poor approach to slicing is cutting a huge story into horizontal slices. Let us use our "World Hunger" example to explain this approach:

We may want to resolve World Hunger in the following manner:

1. Obtain enough food to feed the entire world
2. Gather enough volunteers to distribute this food in the entire world
3. Establish the logistics to accomplish the distribution process
4. Obtain political support (permission, visa, military/police protection) for the distribution

Let us just assume that we had successfully completed steps 1,2 and 3 - but we don't get permission!

We have everything in place, yet there's a bunch of nuts sitting in well-furnished offices who block results for whatever reason or maybe for no reason at all.

While we gind our teeth in frustration and our supplies spoil, people continue to starve. 

A whole lot of resources were wasted, a lot of time was spent - yet there is no visible result!

What happened? Dependent layers were built, and all activities on one layer depend on another layer for success. We can't even know whether our concept works until all layers have been completed, well - at least to some extent. But until all layers are achieved, there is always this looming sense of failure.

(When this happens in the corporate world, you would find some CxO closing divisions, cutting funding and whatnotever that is bad for your career.)

Delivering with vertical slices

As previously discussed, a vertical slice is intended to deliver fast, with limited scope.
"Feed one person for one day" is a limited task, it produces visible, measurable results and permits scaling.
The result from "feed 1 person for one day" is visible and can be subjected to Continous Improvement. Each day, each person contributes to success and regardless of how far we get, the feeling of accomplishment stays with us.

Once 1 person has been supplied, we can enlarge the process to feed 2, then 5, then 10.
All of a sudden, we will see that we are more efficient by centralizing the supply process, so we set up a user story like "As food distributor, I would like a central place where I can always pick up the food baskets so that I save time in getting food to the Needy."
Once we reach 100 people fed, we may get into stories like "As charity, we need media coverage, so that we can obtain funding to feed another 1000 people"
These stories are again, limited in scope, provide a good measure of success and can be completed in a limited amount of time.

Maybe we need to rework our former approach (by Refactoring) but maybe we can just continue doing things as before.

Summary

Lean identifies multiple types of "Waste". One of these types is producing stuff which we can not use yet ("Inventory"). Another type is producing stuff which may never be used ("Overproduction").

Well-sliced stories which resolve (or even better: eliminate) dependencies on other activities serve the team in reducing the risk of delivering features which are not useful for a long time in the future, or - potentially never.

Good Story slicing positively contributes to the visibility and value of results and negatively, eliminates waste.

Therefore, the Product Owner is a key player in enabling team success.

Making stories manageable

As a Human Being, I want to end World Hunger so that there is no more hunger.
Wow, I've written my first user story and it's even correct based on the template. Now my team can get going and because they are Agile, we will have a solution in no time!

What? You have some feedback proposal? ... mmh, okay. :(

Well, poor stories are often "World Hunger Projects" and this one is no different: It's just being a bit more straightforward to realize.

Too many times, in projects I see stories like this one: As a user, I would like to see my data so that I can see what I have to do next.
And the poor developers are stuck with a mess and can't deliver at sprint's end!

Let's take the example of the World Hunger Story to practice a little bit of slicing:

User Roles

Human Being - hmm, that looks pretty big scope. What is your role in all of this?
Are you a human being who is in the fortunate situation of having excess wealth and want to share it? If so, you are a "potential donor".
You maybe the founder of a charitable organization dedicated to actively do something about hunger.
Are you "afflicted by hunger" and need food for yourself? In that case, your perspective is different.
Or maybe you're a "homicidal maniac" and propose dropping a few nuclear missiles on hunger hotspots. (Hmm, maybe as a PO I would pass on that story.)

By identifying different user roles, it becomes significantly easier to focus on what actually needs to be implemented.

Specific goal

Before we get into the What, we must be clear on Why we want something to be realized.
Well, "that there is no more hunger" sounds cool, but it's not all too clear. How can we tackle this?
Let's put ourselves into the seats of a charity organization.
We have a whole bunch of problems, to name a few:

• We need to have something to give to the hungering people of the world:
• Do we want them to have food for the moment?
• Do we want to help them obtain their own food?
• Do we want to resolve a specific crisis?
• We need to obtain funding
• How do we raise our funds?
• How do we manage our funds?
• How do we spend the money wisely?
• We need people with whom we collaborate:
• Do we need speakers?
• Do we need celebrity sponsors?
• Do we need skilled workers who are willing to go into the region?

Each of these is a specific objective to tackle - and even these may still be too big to tackle with just one team and within a limited amount of time, so we may want to get even more specific!
But let's just stick to one goal now.

Specific approach

So, now we are the charity who want go give food to the Needy.
A whole bunch of ideas may come to mind:

• Food baskets for the neighbour in need
• Soup kitchen in the metropoles of the world
• Shipments of wheat/flour/rice to central Africa

Putting it all together to deliver

Now we may create a much more focused story card:
"As a charity, we want to give food baskets to the neighbour in need so that nobody who lives in our community would have to go to bed with an empty stomach".

It won't really solve the entire problem of World Hunger, but it's a step, and you can have visible results in no time.
The team can brainstorm on the contents of the food basket, identify a needy neighbour - and maybe it can be delivered on this very day, working with real user feedback ("Thanks so much for the milk, but I'm lactose intolerant") and improve their strategy from there.

Summary

A good user story helps the team deliver visible results in a very short time without falling into the trap of missing the mark, running into Analysis-Paralysis and many other problems.
Good stories help the team deliver, motivate the team, enable Continous Improvement, allow the PO to check the direction of the implementation and adjust.
And most of all, they provide real value at a limited investment.