How to use User Stories and Story Points properly

Let's begin by explaining what a User Story is.

A user story is a description of a product's functionality or capabilities from the user's perspective.?

It is most commonly used in the form of a template pioneered by Connextra, such as 'As a [user], I want [action] to [benefit]', which is the basis for a clear formulation of requirements.

For example: 'As a customer, I want to be able to add products to my shopping basket to make it easier for me to shop online.

Each user story should include the 3Cs: Card (a physical or digital record), Conversation (discussions that develop the topic), and Confirmation (acceptance criteria).?

While all three are very important, one of them is often overlooked - the Conversation.

A user story should not just be written down on a piece of paper, it should be discussed so that everyone involved understands exactly what it is about.

The user story also needs to be real.

What is a real User Stories

Let's take the example - 'As a customer, I would like to be able to add products to a shopping cart to make it easier for me to shop online'.

This is a good user story, but let's look at what shopping baskets are for in the first place.

I'm sure you've walked into a shop without a basket for just one thing, let's say a yogurt, and arrived at the checkout with three items in one hand and five in the other, praying in your heart that nothing will fall off.

What's more, you probably don't need some of these things, but your brain told you to take them because you were hungry at that moment.

So, the shopping basket is not there to make the customer more comfortable, although that is a side effect, but to make them buy more things in the shop.

Let's consider an alternative story like 'As a shop owner, I want my customers to be able to add products to their shopping baskets in order to buy more things'.

At first glance it's exactly the same, but this story is more true and shows how important the shopping basket is to the shopkeeper, not just the customer.

And now it is useful for two things - firstly prioritisation. The second story has more weight and priority because it shows how important the basket is.

With this higher priority, the shopkeeper will be able to allocate more resources to building the basket, and the team, from designers to developers, will build the basket in such a way that it can hold as many items as possible, maximising the shopkeeper's profit.

This is why the 2Cs, or conversation, are so important and, unfortunately, often overlooked.

Acceptance Criteria should be both business and technical

Finally, there is the third C, which is an acceptance criterion. Usually, it's just technical, but I think it's good practice to split it into two: technical and business ones.

The technical ones are, of course, individual functionalities such as 'add to cart button in a visible place and encouraging to click' or 'product visible in cart after adding', and the business ones correspond to the measurable value the functionality is supposed to bring to the customer, e.g. increase in conversion, increase in average order size and so on.

Story Points

Now let's move on to Story Points - something that is highly controversial and far too often misunderstood by both developers and everyone else, from stakeholders to product owners or project managers.

Story Points are used to loosely estimate tasks, whereas we should not tie them to time.

In short, we compare tasks and assign points to them taken from the modified Fibonacci sequence.

A small task gets 3 story points, a smaller task only 1, a larger task 5 and a much larger task 8 or 13.

If it turns out that another task comes in later then we may need to do task restimulations and so on. The easiest way to determine this is graphically and arrange the tasks in columns.

Those larger than 13, and certainly those with 20 or 40 SP, are better broken down into smaller pieces.

Over time, we can tie in the team's velocity (i.e. the number of story points the team completes per sprint).

What does this mean?

That we can estimate what we will be able to do in a sprint, i.e. what functionality (or several of them) or increment we will be able to deliver in a given sprint.?

Companies often forget that the tasks in a sprint are interconnected and that we often cannot have one without the other (for example, to log in to a portal we have to register first) and that everything is interconnected by various dependencies (registration - OK, but which one, via Facebook, Google, Apple ID or email or maybe all of them at the same time?)

Story points also reduce the time pressure, and thus the pressure on developers, so they can focus on proving higher quality code that better meets acceptance criteria and the definition of done.