Tips to write good User Stories ? (Part 1)

As the scrum guide state, scrum is easy to understand yet difficult to master. Who is presumptuous enough to say they are mastering scrum ? Catching the customer's needs, or trying to envision what would be useful is an extremely difficult task.

What is a "good" story ?

Before talking about methodologies, or acronym , a story describe how the customer or user employ the product.

Get to know your customers, or be sure to represent them correctly, before writing any user stories, otherwise, you take the risk of writing speculative stories that are based on beliefs and ideas—but not on data and empirical evidence.

This should be a must have for all stories. However, as a PO, if you really want to maximize the value produced by the Scrum Team, and I hope you do, there is much more to achieve !

Story title

I like stories which start with an action verb, this makes it easier to understand what this story is about, think about "story telling" when describing the user's journey through the application. i.e "Display the list of product"

Story description

Story often start with the following short sentence, because usually their originate from Post-It card and it is small enough to describe the needs.

As a < type of user >,

I want < goal >

so that < value >.

The real aim is to start a discussion which usually end up much more valuable than what is described on the sticky note.

I.N.V.E.S.T.

This acronym helps to remember a widely accepted set of criteria, or more simply to assess the quality of a user story. If the story fails to meet one of these criteria, the team may want to reconsider it.

A good user story should be:

• Independent

• Negotiable

• Valuable

• Estimable

• Small

• Testable

I'll try to cover each with a simple explanation :

Independent: Stories should be as independent as possible. When thinking of independence it is often easier to think of “order independent.” In other words, stories can be worked on in any order. Why is this important?  It allows for true prioritization of each and every story. When dependencies come into play it may not be possible to implement a valuable story without implementing other much less valuable stories.

Negotiable: A story is not a contract.  A story should beforehand be an invitation to a conversation.  The story should capture the essence of what is desired.  It is the result of collaborative negotiation between the Product Owner, a Developer and a Tester (Know as the 3 Amigos ).  The goal is to meet customer needs. If the development team can achieve that with a quicker, and cheaper solution without cutting on quality, then It's even better !

Valuable: If a story does not bring value, to either the customer or the business, then it should not be done. Hopefully user stories are being prioritized in the backlog by the Product Owner according to business value, so this should be obvious.  Finally, remember the “so that <value>” clause of the user story.  It is there for a reason – it is the exact value we are trying to deliver by completing the story!

Estimable: A story has to be able to be estimated or sized so it can be properly prioritized.  A story with high value but extremely lengthy development time may not be the highest priority item because of the length of time to develop it. (Weighed Shortest Job First principle).

Beware of the time spent on estimating stories, the estimation should only serve one purpose : Is this story easily done in a Sprint ? Is it bringing sufficient value for the time considered to be developed ? If the answer is no, you should probably reconsider it.

Small: Obviously stories are small pieces of work, but how small should they be?  The answer depends on the team and the methodology being used. This also should be in consideration of the Definition of Done (DoD) defined by the team. However, usually I recommend that stories that cannot be realized within 3-4 days should be splitted.

Testable: Every story needs to be testable in order to be “Done.” Even if the "testable" comes are the latest letter in this INVEST acronym, it should not be taken lightly, in contrary, usually stories with up-front defined testing methodology such as Test Driven Development (TDD) or Behavior Driven Development (BDD) are usually more well-formed and makes more sense for developers. This also allow build-in quality which is a well proved Lean Agile Principle.

Definition of Ready

The DoR is a definition which allow every member of the scrum team (PO, SM and Devs) to agreed when a story is "Ready". It usually contains a "checklist" of items to be achieved before a story can be addressed in a Sprint backlog.

Usually, we can find the following items in the list:

- The story is defined we the format "As a .. I want ... So that .."

- The story has at least an acceptance criteria.

- The story should respect the INVEST acronym

- The story has been discussed with the development team

- The story has been estimated.

Everyone one should commit to respect this definition, which mean the PO should not propose a story if it lacks any one if these points, and the developers should not accept a story either.

By not respecting our own commitments, we are lowering our own standard, and it will most likely produce the contrary effects of what was desired.

Every scrum teams members should raise an issue if this commitment is not respected, it is everyone responsibility.