User stories
Hello group, could you help me? Apart from the passenger who is the main user of the system, do you find any other user role for which you should write the user stories of the project?
here is the product description:
The company Plataforma 9-3/4 wishes to implement an online tool for the sale of long-distance bus tickets and has commissioned us to develop it.
In order to use the site, and complying with the regulations of the National Transport Regulation Commission (CNRT), the passenger must register with their personal data (surname, name and ID). The passenger's ID will be used as a unique identifier in the system. For security, during registration the system will request an access code which must be composed of at least 8 characters, including at least one character in lower case, one in upper case and one that is a number. At that time, the passenger can associate a credit card where the ticket payments will be charged.
To purchase a ticket, the passenger must establish the origin and destination and the desired day of travel. Then, the system will search the systems of each associated transport company for the services that meet the passenger's search, the characteristics of the bus, the free and occupied seats and the intermediate route. The system ready to the passenger all the services with availability, with the name of the company and the departure and arrival times. The passenger will then be able to filter these results by a particular company, by a range of arrival and/or departure times, and by ticket cost. When selecting a service, you are shown a schematic view of the bus, highlighting the available seats. The passenger can select one or several places to occupy, and then proceed to complete the purchase. At the time of completing the purchase, the passenger must complete their credit card information. If you have an associated card, the fields will be loaded: card number, issuing bank and credit card brand. Otherwise, the passenger must complete them manually. If you selected more than one seat, you must associate each one with the document number of the passenger who will occupy it. The system will check if such a document exists in the system. If so, the system will fill in the corresponding first and last name and notify the corresponding passenger. Otherwise, the passenger must complete the fields name and surname.
When the details of the card and of the passengers are complete, the summary of the card will be displayed and the passenger will be able to confirm the purchase. The system will charge the cost of the ticket to the card, it will charge the occupation of the seats in the service to the transport company's system and it will send the tickets to be printed to the passenger's mailbox.
The company Plataforma 9-3/4 agreed on a strategy with the transport companies El Gorrión and Langueyú to reduce the number of empty seats on trips. For this, six hours before the departure of a bus that has more than 20 free seats, those interested will be notified of the sale of the ticket with a 50% discount. Passengers who are interested in these promotions must subscribe in advance through an option called "Travel
improvised”, indicating the origin and destination, to receive alerts by email. Since bus passengers often make the same trip periodically, for work or study, you can sign up for these alerts when you buy a ticket.
One of Plataforma 9-¾'s own strategies will be to provide statistics on the services. To do this, it will use the passengers' cell phones. Those passengers willing to participate in the generation of statistics must enter the Platform 9-¾ page in their cell phone browser when boarding the bus and, being logged in, select the “follow” option. At that time, the system will collect the information of the ticket purchased by that passenger that coincides with the activation time and will begin to send the position indicated by the gps to the server every 10 minutes. Upon arrival at the destination, the passenger must stop the shipment by selecting “stop following”. If you forget to select this option, the system will automatically stop issuing the GPS information when 130% of the estimated travel time is fulfilled. To encourage passengers to use this functionality, you will be given a $10 credit that will accumulate in your account to be discounted at the time of purchase. The average length of service for the last month will be displayed at the time of the search.
Finally, the passenger may return tickets, complying with the rules of the CNRT. The regulations authorize the percentage of refund, according to the advance to the date of the trip in which the refund is made: More than 48 hours, 90% of the amount paid is returned, between 24 and 48 hours, 80% of the amount paid and
Apart from the passenger who is the main user of the system
You've recognized the passenger as the main user of the system. Which others do you think may have a use for it, and might expect certain outcomes? Bear in mind that the product description did not write itself.
Apart from the passenger who is the main user of the system
I see a number of potential users. Remember you are writing this system for a company. Wouldn't individuals within that company be users of the system and the data that is collected? Could it be possible that the Transportation agency might have need of regulatory data since they are requiring specific data be collected?
But, in my opinion, I wouldn't write any user stories for this. Apparently you have already worked with your Developers to create the specifications and have a very good idea of what you want to create. So what purpose would the user stories serve? Why not just write Product Backlog Items that explain different parts of the system in a way that completion of them will create a usable increment of value?
User stories are a good way of conveying the business need from the perspective of a particular type of user when there isn't a clearly understood design. You are past that point.
If I only take into account the description of the indicated product, I would believe that the employees of the company who request the online tool might want to have a use for them and consequently obtain a result. I wrote the following user stories for them but I'm not sure if the user role would be correct:
1-As a company, I want to offer 50% discounts on low-crowded services, to boost the number of passengers traveling on them.
2- As a company, I want to collect information and obtain statistics on the different services, tracking user trips, to have control over their effectiveness and translate it into the staff of each one.
Another option that I have in mind is to assume that there is a site administrator (who is not indicated in the description) who might want to have a use for it and consequently obtain a result for example:
1-As an administrator I want to be able to add a transport company associated to the system to offer its transport services on the site.
2-As an administrator I want to be able to add a transport company to the agreement in order to be able to offer its discount tickets for services that are not very crowded on the site.
I feel confused about it ='(
If you are having this much trouble trying to force user stories for the work, I reiterate that you might not need to use them. This is a common problem with user stories. Not everything fits into the "As a ... I want to .... so that ...." model. Sometimes you just need to list the expected behavior in bullet lists.
It is a job for the university, if or if I should identify the user stories. Clearly what you say happens to me but I must do it.
User stories (US) have evolved over the years. Almost like a snow ball rolling down a hill, accumulating practices as it went. The format you are referencing is one of the approaches that the US snowball has picked up along the way.
If you remove some of the layers from that US snowball , it would bring you back to basics. Card, Conversation and Confirmation (as an example) or simple bullet points as Daniel mentions. Good to keep this mind when we find ourselves making up personas or manipulating words just to make the approach work.
Instead of...
As a company, I want to offer 50% discounts on low-crowded services, to boost the number of passengers traveling on them.
You could have "Boost the number of passengers travelling on low-crowded services by offering 50% discounts".
As an aside, I am sure the company doesn't want to offer 50% discounts on low-crowded services. What they likely want to do is boost the number of passengers, with the discount being an experiment to try in order to achieve that boost.
First of all don't let yourself get confused by terminology
Even though the term "user stories" is widely used, Scrum does not have any actual "user stories", there are Product Backlog Items (PBI).
Product owner is currently only person who is allowed to add items into product backlog(or allow others to do so)-I suggested to change this rule at this post but its a seperate story.
One thing to remember is that disregard of the source where the actual PBI coming from-from your passengers, bosses of the company, or Product owner is writing them out of his head, its Product owner who is solely responsible for a content of Product backlog.
As for your practical situation, your Scrum team has two important dimensions to be considered-actual end users of your product, passengers, and stakeholders-the owners and directors of the company who have hired your Scrum team.
Feedback from both sides must be taken in consideration if Product Owner wants to have a good Product backlog. With end users being more important but not necessarily most valuable.
How about a "client"?
Is it possible to order 2 tickets in one order?
I perfectly understand what they are referring to, the issue is that I must express the product's PBI's in user story format. I also understand that I must take into account the comments from both sides (the passengers and the company that requests the product).
I am clear about the PBI's expressed in user stories that represent a business value for passengers.
What I do not quite understand is, for example, if it is correct to use "The company Platform 9-3/4" as a user role to express the pbi that for me provide a business value such as the following:
1- As a company, I want to increase the number of passengers traveling on low-crowded services by offering 50% discounts.
2- As a company, I want to collect information and obtain statistics on the different services, tracking user journeys, to have control over their effectiveness and to be able to show the average duration of the service at the time of the search.
I am confused by the idea that user stories should be written for the end user who is going to use the functionality/feature and get a result from it.
It is obvious that the passenger will use these functionalities but the rest will be done automatically but even so they will deliver a business value in this case, in my opinion, to the company requesting the product.