If you’re excited about this title, I’m guessing you’re most excited about this post since we talked about Agile frameworks. User stories are now a common tool for describing requirements in Agile. When it comes to Agile, you have to ask about user stories. All the things we’ve seen before, the to-do list, the iteration sprint list, all of that stuff, it’s all about user stories. In the sprint, the whiteboard, the task board, are all user stories. Do you know how to write a real user story?

User story format

User stories describe desired features from the User’s point of view. A good user story consists of three elements:

  1. Role: Who will use this feature

  2. Activities: What functionality needs to be accomplished

  3. Business value: Why is this feature needed and what value does it bring

With these three elements, we can conclude a standard format for a user story:

As a {role}, I want {activity} in order to {business value}.

Let’s take an example: as a “migrant worker”, I hope “it is convenient to buy train tickets”, so that “I don’t have to queue at the railway station in cold weather”. Through this user story, 12306 was born.

Of course, the scope of this story is actually a bit too big, how to buy a ticket, how to choose a seat, how to queue online and so on can be broken down into more detailed stories. We also call this kind of large-scale story an Epic. This story is not a good story, and this story is probably a relatively good one.

As “company operations”, I want to “see the number of newly registered users” so that I can “count the new effects of the product”.

It is important to note that user stories should not be described in technical terms. The above story is a bit technical. We should try to tell a story about what we want to do from the point of view of the customer and interested parties. The technical language comes after the user stories are assigned and broken down into tasks in the iteration. Of course, it’s okay to talk about user stories from people inside the company, because these aren’t technically specific terms.

A common user story is written on a card, also known as a user story card. For this user story card, there is a three C rule.

  • CARD: Written on a CARD, easy to record and discuss, and easy to move around on the task board.

  • CONVERSATION: The details behind the user story should come from a discussion with the customer and various interested parties.

  • CONFIRMATION: Use acceptance tests to communicate and document the details of a story and determine when it will be officially completed.

INVEST principles

The THREE Cs above can be thought of as the rules for creating a user story card, but there are also hidden rules for writing a user story. However, no user story is a good one without these six features, and many people would call these six basic principles of user stories. The first letter of these six principles is the word INVEST, which, interestingly enough, means investment in Chinese. User stories really need to be built and defined with the dedication of our teams and stakeholders.

Independent (Independent)

User stories should be independent of each other. Is that user stories don’t depend on each other. If there are dependencies between user stories, then the dependent user stories have an inherent priority. , of course, this also is, indeed, there is no way to avoid, as we want to develop integral function, it must be to develop user center function, and to develop the user center, it will also have to want to have a login, in the case of user tables are not sure, then back and user related functions could really can’t do the implementation.

So there’s no way to solve this problem? Let’s just say we want to break down the stories as small as possible, and then try to make the stories within this release as dependent as possible during a release cycle.

Negotiable (Holder)

A user story is not a signed contract, it is a description of a user’s needs and does not contain too much detail. Therefore, user stories should be negotiable, and if too many restrictions are defined from the outset, they will not be communicated and negotiated. Because the details and limitations should be determined during development, after the user story is broken down into tasks. At the same time, the negotiation that developers can participate in allows user stories to gain more developers’ approval and support.

Be Valuable

The word value is actually no longer needed. There have been several articles devoted to value. If user stories have no value, what are we delivering? I thought we talked about customer value driven delivery. The best solution is to let users write their own user stories, if not convenient, then the user agent or PO should try to stand in the user’s point of view to write. The average user is more than willing to try to write their own user stories, knowing that they are not a fixed documentation backlog or a contractual constraint.

Estimable

In general, the bigger the story, the less estimable it is, like the epic story we mentioned above. Seems to be very simple ah, can buy train tickets on the Internet, that you know how many times 12306 version, think how many methods just let us now can more smoothly buy train tickets? This is a bit like joking when said, party A said the demand is very simple, just do taobao. This kind of thing, in fact, is really too virtual to calculate, so the solution, the split, the split step by step, has to be small enough that the developers can do it in one iteration. In addition, domain knowledge is also very important for estimation, without the foundation of domain knowledge, the estimation gap may be very large. Agile does not value accurate estimation, but it is not acceptable to be wildly off.

Small (Small)

Well, I’m going to start talking about this little thing. A good story must be as short as possible in terms of the amount of work. The problem of estimation error has been mentioned before. The smaller the story, the more accurate the estimation is, and it must be completed in an iterative sprint cycle, which refers to the consensus of “completion” after passing the test. Of course, being too small is not a good thing, and a trivial list of stories can cause major maintenance problems. The need to change the color of a button on a page, or change the word, would be better incorporated into a story of the right size.

Testable.

This feature is very important for user stories. Why is that? We just talked about the “done” problem. A test is a standard by which you can verify that it is “done.” In addition, user stories provide the basis for test cases, and the completion of tasks is measured against the pass rate of unit test cases when dividing tasks. So it’s about how we end this story. For example, a user story is that the system should be easy to use, easy to use something that can’t be tested, and it can’t be estimated.

conclusion

User Stories, one of the most famous, and number one recommended study materials for the PMI-ACP exam, is User Stories and Agile Methods by Kent Beck, founder of XP. This book is a highly recommended introduction to Agile whether you are taking exams or learning. In fact, there are not many examples of user stories in today’s article. The main reason is that I don’t have much experience. I have led agile teams only once before, and the gap is quite long. But there are so many, so many good examples in this book that I really recommend you buy them.

Reference Documents:

Textbook of a Training Institution

User Stories and Agile Methods

“Effectively Pass the PMI-ACP Exam (2nd Edition)”

Agile Project Management and PMI-ACP Test Taking Guide