Storytelling is one of the oldest and at the same time most difficult activities we have had to deal with over the centuries. I'd even be tempted to say that if we hadn't mastered this art, our culture wouldn't have developed so phenomenally - all the world's religions, described histories of societies, instructions for objects, regulations and laws are based in some way on storytelling. Some of them are told better, others worse. Some thrill, throwing the audience into a whirlwind of events, while others, on the contrary, condemn themselves to oblivion.
It is worth noting that every story we convey is created for a specific purpose. Most often so that others can remember or use it. Already Aristotle came to the conclusion that man by his very nature strives to know more. In fact, it's not just about the information - the information itself we as humans are unable to remember until we make sense of it. According to research, people who were given dry data - remembered it much worse than people who were told a story, weaving the same data into it. The conclusions are obvious - a properly told story can work wonders when it comes to motivation, commitment and goal achievement.
Groups of specialists
For centuries, the knowledge that one person had to possess touched many areas of life. The scope of this knowledge within a single area was not great, so our ancestors did very well. Over time, however, virtually every area of life developed to a very high level. People began to specialize, at the same time creating their own - domain-specific language, which they used in their company.
It is very easy to see this in groups such as medics, lawyers, salesmen, priests, architects... and today also programmers. Each group of specialists has developed its own technolect. The main feature of professional languages is the creation of morphological simplifications in order to optimize the message, so that it becomes more effective.
Examples of phrases and words from the language of programmers are: ai, backend, bug, code review, devops, conversion, class, merge, nerd, version control system... and many others. For people outside the industry, understanding sentences containing technolect is very difficult and sometimes impossible.
Communication tools
In addition to professional language, industry communications very often use specific tools with which specific messages are formulated. Such a tool would be a piece of legislation for lawyers, a medical chart for doctors or an API (application programming interface) for programmers. An API is primarily a guideline specification that describes how to communicate between different parts of an application and/or external services. One is definitely tempted to say that an API will be understood by one professional group.
The aforementioned tools have their own specific content structure, use technolect and fully understanding the content in them requires very specific knowledge. In other words - it is not easy. Fortunately, in most cases we do not need to use these tools directly if we do not belong to a particular group of professionals.
However, there are times when professional worlds intersect. This can be seen quite often in the IT industry, as more and more areas of our lives are beginning to merge with programming. First of all, this is because our world is virtualizing and there are applications for "ordinary" people, created by programmers on behalf of people outside the IT world. The principals have to convey their idea in a way that the programmer can understand.
They can do this with a tool called User Story (US).
Domain knowledge
At this point it is worth mentioning domain knowledge. Domain knowledge is nothing more than knowledge of the domain in which an application is developed. It is much easier for developers, specialized in some business area, to understand the customer's requirements and deliver the right product. Sometimes they can even suggest a solution or direct the customer in the right direction. Knowing the business helps a lot in software development and communication, and thus in delivering optimal solutions.
What is a User Story?
User Story is a tool that is used to describe requirements in software development. As a rule, User Story should use a language that both technical and non-technical people can understand.
What kind of language is it? As simple as possible. Given that it must be understood by two different groups of professionals, technolect should rather be avoided.
User perspective
In other words, User Story is an informally written requirement explaining the behavior of a program written from the user's perspective. The last part of this sentence is very important. It indicates that the user is the audience and it is important to him how the program will behave. A programmer who analyzes such a User Story will be able to better understand the needs and expected behavior of the functionality.
"Story" should describe a specific benefit for a specific person. It is worth noting that the user from whose perspective it is created is not always the end user. Sometimes it's another member of the development team, sometimes it's the system administrator, and sometimes it's the customer.
Agile
User Story as a tool is very often used in agile project management (agile) methodologies. Admittedly, this is not an article about Agile, but it is worth mentioning that agile management is all about flexibility in delivering working solutions. In agile methodologies, the US is referred to as the smallest unit of work. Dividing work into small "stories" allows you to maintain a fair amount of flexibility, by selecting work tasks for the near term accordingly.
How is a User Story built?
Like any good tool User Story also has its specific features that make it an effective tool. One feature I have already mentioned - simple language. The second feature is the structure. A good "story" touches on three aspects:
- defines the user / audience
- defines the needs
- defines the goal to be achieved in relation to the need.
Example:
As <użytkownik> I want
User Story should not be too detailed. It should focus on the goal to be accomplished and state the motivation behind that goal. The above example is usually used as a headline for the entire "story". In addition to this basic section, Acceptance Criteria (sometimes also called Conditions of Satisfaction) should be defined in the US. Acceptance Criteria (AC) is nothing more than a list of requirements that must be met to state that the US has been completed. In practice, ACs are often referred to by the term Definition of Done. Proper DoD definition prevents untested or incomplete solutions from being delivered to the end customer.
It is also common to find that a well-prepared User Story should have an estimated size (it cannot be too large), a defined value and a defined place on the to-do list.
Five W's.
In the practice of creating a User Story, one may also encounter the Five Ws principle. The principle takes its name from five words: who, what, when, where and why (who, what, when, where and why). It is often used in journalism to create press releases.
Applying the Five W's rule in building a "story" looks like this: As
Writing Acceptance Criteria
I have already mentioned what Acceptance Criteria are and what their task is within the User Story. This leaves us with the question of the form of recording. Actually, we can encounter two approaches. The first is to write down in the form of simple sentences or sentence equivalents things, usually in the form of a list, that should be realized.
We can also encounter another approach, using Behavior Driven Development, where acceptance conditions are defined as scenarios, consisting of a name, conditions, a trigger event and an expected effect. For example:
Scenario:
There will be as many such scenarios as there are requirements for a given US.
INVEST principle
A well-prepared User Story will help prioritize the project, which will ultimately translate into the efficiency of work delivery. Despite few rules, it is very easy to get lost and forget important aspects of creating "stories". To avoid this, it is a good idea to use the INVEST principle when preparing them. INVEST is an acronym for Independent, Negotiable, Valuable, Estimable, Small, Testable. Let's take a look at the following points:
Independent
I mentioned that US is the smallest unit of work in agile projects. It is worth emphasizing here that it should also be independent of other "storylines". This means that the team that will solve a given US can do it in isolation from the rest. The order of tasks should be based on business need, not on the relationship between USs.
Sometimes this can be difficult, but often it is not impossible to do.
Negotiable
In earlier points I mentioned how important it is to understand the requirements and for whom the functionality will be implemented. This point indicates the value of creating a User Story together. A good "story" is the result of collaboration between the team and the customer, where each party can add their own comments, insights and ideas as part of the discussion.
Valuable
This point is probably raised most often of all. US should carry value for the end user, it should be important for the business.
Estimable
Any task the team will be working on should be as estimable as possible. If the labor intensity of a given User Story cannot be determined then it is difficult to say for when the result will be delivered. From a business perspective, such a situation is unacceptable.
Small
"Story" should be as small as possible, so that it can be closed within the time frame. With smaller tasks, there is not as much risk that something will not be delivered or that there will be additional aspects that we have not thought of. Unexpected things are one of the biggest enemies of productivity.
Testable
Acceptance Criteria should be easy to test. Based on them, testers should be able to build clear and specific test scenarios, and developers should seamlessly know how to check if their solution works.
Definition of Ready
Above I described most of the characteristics of a good User Story. Unfortunately, life shows different scenarios, and there are situations when "stories" are not complete, do not have clearly defined conditions of acceptance or simply cannot be estimated time-consuming. When creating a User Story, we may also encounter the Definition of Ready principle, which tells us that a task can be considered ready for execution if the team states that it understands the requirements and they are adequately described. Something that has not been approved by the team cannot be included in its work. This is why it is so important that all members of the team participate in requirements gathering and consultation. This approach gives everyone involved enough knowledge of the task at hand.
Summary
Communication is an essential skill within any project. Without open communication based on clearly defined principles, it is difficult to build something of value. Going back to the beginning of this article - it's worth noting that the more we know about the world, the harder it is for us to communicate between different specialties. Tools such as User Story go beyond the communication pattern of one specialized group, opening it up to other professionals, thus creating products that touch multiple fields. Of course, US isn't perfect - it's very difficult to use it to describe typically systemic problems (such as technical analysis or software bugs), it can also be problematic to pay too much attention to business solutions, overlooking optimizations, or to lose the overall vision of a project due to the high fragmentation of tasks.
Despite this, User Story allows to understand what should be done by each party, set priorities and increase the usability of the solutions created, thus skipping work on solutions that might never be implemented production-wise.
Sources
- Domain knowledge - Marek Hare
- Developer's glossary - phrases every Junior Developer should know | Future Collars Blog
- A glossary of IT terms for novice programmers and more!
- Professional language - Wikipedia, the free encyclopedia
- User Stories and User Story Examples by Mike Cohn
- User Story - what you should know about it
- User stories | Examples and template | Atlassian
- User story - Wikipedia
- Visual Storytelling - Monika Gorska
- How to write a press release? - E-volontariat.pl
- How to build a User Story? - "Scrum and Beyond. Theory and practice in Agile methods / Programming / Articles / IT PWN - IT.PWN.PL
- Definition of Ready - advantages and disadvantages - #protein or Scrum And Agile
- What is user story and acceptance criteria (examples) - Agile Testing 14. DONE Understanding Of The Definition Of "Done" | https://www.scrum.org/
- What is acceptance criteria? | Definition and Best Practices
- Appchance - How and why to create User Stories.
