A solution of communication problem between business and technic: User Stories
It is common that so many companies face the “blaming each other” issues between business side and development side. In detail, there is “the developer” who blames the business side for not giving the clear software requirements. There is “the product owner & business analyst” who blames developer for not doing the correct work. And of course there is also another side of this blaming session, customers. Generally they are the ones who suffers from this problem. Cause generally the output of this affects the delivery. In this kind of companies, it is quite rare to see a successful delivery. Yes they deliver something, they complete a task. But to be a successful delivery, it is important to create a great value. In this case even the stakeholders of the project cannot align themselves, how can we wait from these stakeholders to create great value?
Nah — right.
Q- So how do we create great value?
A- By solving the communication problem.
Yes, software requirements is a communication problem. Those who want the new software (either to use or to sell) must communicate with those who will build the new software. To succeed, a project relies on information from the heads of very different people: on one side are customers and users and sometimes analysts, domain experts and others who view the software from a business or organizational perspective; on the other side is the technical team.
If either side dominates these communications, the company & project loses.
So if business dominates the communication, then it mandates the functionality and dates. It can create huge gaps on technical side.
If technical team dominates the communication, then the technical jargon replaces the language of business. It can create huge misunderstandings on what is needed.
In both cases, there can be an end-product, but it may not create any value or it may create barely.
So this is how and why user story stories born, to solve the communication problem. They were created to build a shared understanding between business & technical people and to identify the users and their problems.
One of the goals of user stories is to get people talking rather than writing.
So, we understood the problem.
— It is communication & alignment.
So, we understood what happens if one side dominates the communication. — Project x company fails.
So, we understood the solution.
— User stories.
Then
What is a user story?
A user story describes functionality that will be valuable to either a user or purchaser of a system or software. A simple descriptions of a feature told from the perspective of the person who desires the new capability.
They are composed of three aspects:
• a written description of the story used for planning and as a reminder
• conversations about the story that serve to flesh out the details of the story
• tests that convey and document details and that can be used to determine when a story is complete.
-User stories are typically follow a simple template:
As a <user>
I want to <some goal>
So that <some value>
—
There is a user who is going to benefit from the work.
There is a goal, which is expected to achieved after the work.
There is a value, which is the main reason why we do the work.
We will explain about how to write user stories in future articles. Before that you need to understand that user story concept created in early 00's.
It is first mentioned in;
Kent Beck’s book “Extreme Programming Explained”. It was unstructured text that was quite similar to use cases with restriction in size.
-In 2003:
The INVEST checklist for quickly evaluating user stories originates in an article written by Bill Wake, which also repurposed the acronym SMART (Specific, Measurable, Achievable, Relevant, Time-boxed) for tasks resulting from the technical decomposition of user stories.
-The next year 2004:
Mike Cohn published the book “User Stories Applied” which recommoends the INVEST acronym is among the techniques.
In this series, I will explain about;
- What is a user story and how to write them.
- What is Customer Team?
- What are those INVEST principles?
- How to use user stories for project management?
- How to use user stories for Continuous Integration?
Plan is to complete user story topic in with 4 different articles. So this is the first of them, I will put the links here whenever they completed.
Second article: INVEST in User Stories published. You can find it here:
See ya!
