User story — the story that makes sense
This article is about what the user story is, where they came from, and how to use them right.
Probably lots of you already heard about such thing as a ‘user story,’ and you wanna ask me how anyone could use it wrong. But according to my experience, it occurs pretty often.
I often hear a story from developers that their project uses Scrum methodology, it does not work for them, and this ‘hyped stuff’ has nothing useful underneath and was created only with one purpose — increase number of meetings to distract developers from coding. And yes, they also think that it’s the only reason why scrum masters exist. Last four months, I participated in interviews for middle QA positions in our company and heard from lots of candidates that they’re working by modified Scrum or (and worse) almost pure Scrum. But as soon as I started to listen about their processes on a project, I figured out why most of the people are saying that “Scrum is not suitable for us” or it has nothing useful except a considerable amount of meetings.
Why am I writing it and how is Scrum related to all of this? You’re right, User story itself isn’t strictly attached to Scrum and can be used in any type of Agile methodology. But, in my opinion, in such a way, they show the best impact. Also, I’m using Scrum as a convenient allegory for User stories to show how much both of them are underscored, and that’s why they bring more harm than benefits.
Ok, so what is this User story after all? Generally speaking, this is a methodology of describing requirements by describing user behavior. And yes, it is BDD (behavior-driven development), which many of you, I’m sure, may have heard about. The essence of this approach in describing the functionality of your app through the behavior of the end-user. Often, for this purpose, use some kind of templates, for example, Gherkin, which uses keywords Given, When, Then. A typical story, in this case, looks like the story below:
Given I have an account in my system. When I open login page And enter my credentials And press submit button Then I should be navigated to Dashboard page.
This way of describing is familiar to Business Analytics and how strange it may sound for the Automation QA, in the case of Analytics everything is pretty clear, they work with users, metrics, and make requirements. But what about Automation QAs? I guess some of you already understood where that knowledge has come from. It’s all about the Cucumber framework. The central concept of this framework is BDD and using User stories as test documentation and tests itself. The idea to combine instances in one (user story, test case & test) seems quite brilliant, I agree. But as always, we face cruel reality.
I met a lot of QAs, who write their tests using Cucumber and Gherkin, and each one of them has told me how cool it could be — to combine test documentation and the tests itself in one entity. But as long as I asked them, “Did somebody beside QAs look in it?”, the best answer I’ve ever had was: “Sometimes developers could look which tests were failed.” And this is one more example of how the original design of User Story can be corrupted. When artifacts and methodologies used without a clear understanding of their purpose or when it used only cos it in trends, not cos it could solve any of your problems.
Or, perhaps you may be familiar with a situation when User Story is used to describing the task, but did it only post factum. Then the task has already been described, estimated, and you do it just cos Jira will not accept the task without a story in it.
All the above are examples of lousy formalism when you are using the tool only cos you have to, without an understanding of how it should be used right. It is the same as if you have a pneumatic hammer, but instead of turn it on to use it right, we start to knock nails with it without understanding the whole complexity of the tool.
Anyway, where did this User Story come from, and what problem does it solve? Here comes an easy part — at the beginning, it was a story from end-users, who contacted the support with their issues and propositions for improving the software. An average message looks like this: “I’m a counter at some company, when I open reports page I wanna have the possibility to filter data by the reporting periods.” This stories fell to the dev team in their original form, without any changes. And dev team, based on this story, could assess complexity and break them into smaller tasks. This is where such methodologies like grooming and story points came from.
I.e., the task came from end-user in its original form, and Business Analyst could estimate its priority and transfer to the dev team for the implementation. Dev team, in their turn, at the stage of grooming, can estimate the complexity of the task. And as you can come up with, they don’t do it in hours, but in points, only saying how difficult it would be to implement. After this story passed to the planning stage, previously decomposed into small technical tasks and can be ready for implementation.
Everything described above sounds logical and happens quite harmoniously, as it serves a specific purpose, and does not exist just cos it is customary. First, there was a desire of the user for the particular functionality, and he knows what he needs this functionality for since he spent his time on the description. It is followed by the stage of prioritizing according to the business needs. After that, developers evaluate this story, and when it’s ready to take part in planning, where devs could add some more specific and technical descriptions, risks, etc. You can admit that in such workflow is quite hard to do something wrong, e.g., to start estimate tasks in hours, since it’s just crazy cos the story stands for a massive functionality with a lot of unknowns.
In conclusion, I wanna say only one thing, if you feel that you are doing some kind of Scrum ceremony without fully understanding why and what problem does it solves, then you should stop and think. You should not write User Story just cos you’ve been told to do so. If your team has a lack of user feedback, later at least try to describe the functionality through user behavior (BDD one more time). The key metric should be the impact on the end-users after this feature goes live.
