Back to articles

give me problems to solve, not solutions implement

For a long time now I’ve generally been working to deliver user stories.

If you are not familiar with a user story it will probably look something like this:

Scenario: User adds item to cart

Given I'm a logged-in User When I go to the Item page And I click "Add item to cart" Then the quantity of items in my cart should go up And my subtotal should increment And the warehouse inventory should decrement

An example stolen from How To Write Well-Formed User Stories.

This is a great way to give shared understanding to a team. It sets out a clear context, action, and outcome without talking about the implementation.

Most of the time when I am given a task, it isn’t as clear, the context and outcome are generally missing.

This can also result in the person doing the development narrowing their focus and not focusing on the actual outcome, just the implementation.

A good example of this is ‘just add a back link’. While adding a link between two pages is easy, it doesn’t explore the problems.

In this situation, there was no context, expected outcomes and no clear understanding of the actual need.

In this case, the user wanted a back link so they could go and make changes to the address.

This meant adding a backlink wouldn’t have solved the user’s problem.

context: Given a user has entered an address action: When they are on the PDF screen action: And click back outcome: Then they are shown the address screen outcome: And can update the data

This makes it much clearer what the user is doing, and the expected outcome, which should lead to a better implmentation.

I always feel more rewarded when I undertake this sort of work - even if the outcomes are very similar. Owning and delivering a story is very different to completing a task.

Because this is in a gerkin, this can be used directly in an automated testing framework.