About User Stories

User Stories are very central in any Agile methodology and very often are the first cause of a failure (or success) in a software development.
Speaking about User Stories with a colleague in London, I noticed like the topic is every time (no matter the Country nor the person) much more complicated than expected, mostly if you are new on the field.

If you speak about User Stories is quite simple that, at the question “How a User Story should be?”, your answer will probably be an emphatic “INVEST!”
I agree, but I’ve noticed that to apply the INVEST approach is much more hard than expected. The theory is pretty clear, but somehow not so much clear how to put it in a User Story.

The first question that I receive after a quick introduction to User Stories is “How much small? How much big?”.

“How much small?”
A User Story should bring business value independently by other User Stories. If you can bring business value, even a bit, the User Story could be a good one.

“How much big?”
This is hard, in theory the smaller, the better, but sometime it is not so simple because of different reasons. In my team worked the rule: You should be able to close it in a Sprint.
But we avoid to have a User Story that needs more than half Sprint.

“What about the Business Value? How can I measure it?”
It is a good question indeed, the answer won’t be very short.

When you define a Software in a non-agile approach you typically write down a lot of technical requirements, functionality etc etc.
So a typical task for a team could be “You should create a registration form”.
It is a simple example, and for sure it is clear what you want, but as a User Story is not so good.

User Stories are about (spoiler alert!) User not technical requirements.
So a User Story should be a feature that solve a specific need for a specific type of User.

Using the example above:

As a User of the website
I want to register
In order to access a custom private section.

Let’s put them side by side

As a User of the website
I want to register
In order to access a custom private section.
You should create a registration form

Apparently the result you will achieve will be the same, but they are very very different.
The one on the left side doesn’t suggest a technical solution and it is pretty clear why and who wants to register in the website.
If you give to the DEV team the story on the right side they will create for you a form, without to know why and so they won’t be able to hypothesize and suggest maybe a better solution or they won’t be able to tell you that your assumptions are wrong and to fit the specific User need it would be better put in place a different strategy.

In this simple case maybe the creator of the story and the DEV Team will come to the same solution and the form will be created in any case.

Or maybe the DEV Team knows that is possible to register people via webcam using a face-recognition strategy.
If you suggest a tech solution, your DEV team won’t unleash its potentiality and you risk to lose value, much more value than you expected.

Let’s think your DEV Team.
Its job is to find the solutions, the job of the Product Owner is to know/define what a User need.

So avoid to go technical in your User Story description.

But the question is still there: “What about the Business Value? How can I measure it?”

Using the format:
As a <type of user>,
I want <some goal>
so that <some reason>

you are able to show the User Story and discuss them with your Stakeholder and exactly as the same way the Team plays “planning poker” to define story points during the Sprint Planning, you can play with them a “planning poker” related to Business points.

The feature is formulated in a very clear way, perfect for no-tech people, your Stakeholder are able to understand the meaning and they can give you a relative value to each story.

In my perfect world (that often it exists only in my dreams 🙂 ) at the right bottom of a User Story there are story points, at the left bottom there is the business value.

When the Team estimates a User Story during a planning it’s possible that the story was written and discussed with the Stakeholder long time before, so to have a Business value on it makes easy to decide if maybe the effort not worth it.

In general your able to prioritize the User Story more easily.

So: “What about the Business Value? How can I measure it?”

Short answer: meet the Stakeholders 🙂

At this point, commonly, I receive this question:

“With that Formula the User Story is clear, but without any kind of tech detail how and when the Team can know that it is done?”

Well, for sure “ it depends on Definition of Done of the Team” is a part of the answer, but every User Story should have one or more Acceptance Criteria.

In the Acceptance Criteria you can put your expectations about the behaviors or the limits of the story:

As a User of the website
I want to register
In order to access a custom private section.

  • The user should provide a valid email
  • The email should be unique in the system
  • The user should provide a password, the password should be inserted twice.
  • It should be a CAPTCHA system to avoid bots.
  • In case of error the User should be redirected to the registration page with a graceful error message, the form’s fields should be filled with the information provided by the User

The Acceptance Criteria define in some way the scope of your User Story, they should be negotiable with the Team because they are responsible of the effort.
Above I said that “the smaller, the better” and some Acceptance Criteria can make your User Story much bigger than expected.
In general I suggest not to put to much constraints or details, you should put only the minimum you need to have the feature valuable and testable from the point of view of your business/Stakeholder.

Let’s assume that the Team says the Story’s cost is 5 points.

What if we remove CAPTCHA from the Acceptance Criteria? We are not releasing now, the CAPTCHA will be put in place before the release, in another Story that will refine the Registration workflow.
Do we need the CAPTCHA now to show the feature, the registration workflow to the Stakeholders?

Maybe no, so what is the cost if we remove the CAPTCHA?
Maybe in this case won’t change, the Team (or the Company) has a standard library to solve the problem, or maybe it will change a little because the Team should use time to find out a good library and to learn to use it, or maybe it will change a lot because in the project there are strong constraints about third party libraries and the Team should develop the CAPTCHA from scratch…and so on.

The point is that everything should be negotiable: until the User Story has a business value (even a bit) you can slice it or its Acceptance Criteria.
Discuss your stories and acceptance criteria with the Team.

Generally speaking it’s hard to find an unique way to define good User Stories, the rule of thumb is a good approach and even the “good enough” approach is a good idea when you write the Acceptance Criteria.

If you need more information about the topic you can take a look to the Mike Cohn’s website.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s