Merge branch 'maoragbe-main-patch-42791' into 'main'

Update getting started/User stories.md

See merge request !2

getting started/User stories.md

 # User Stories
+User stories were first mentioned as unstructured texts similar to use cases with restrictions in size in Kent Beck's book "Extreme Programming Explained."In software development and product management, a user story is a simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They represent a way of communicating or articulating the requirements of a system on the needs of the customer (those who want the system ) to those who will build or develop the system. 
 
-MAMIA WILL WRITE AND PRESENT THIS
-=================================
+User stories are typically used in the Agile software development methodology, emphasizing the rapid and flexible response to change. In Agile development, user stories are used to capture the requirements for a new feature or system. They are used to facilitate the conversation between the development team and the customer or end-user and help the team understand the desired outcomes and benefits of the feature from the user's perspective.
 
-In software development, a user story is a short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. User stories are used to articulate the requirements of a system from the end-user's perspective and are often written in the form of 
-> "As a `[type of user]`, I want `[some goal or desired action]` so that `[some reason or benefit]`."
+In the context of DevOps, user stories can help teams align their development and operations activities with the needs and goals of end users. By focusing on the user's perspective, teams can ensure that they are building and operating systems that provide value to users and meet their needs.
 
-Links for more information:
+## Functionalities of user stories
+User stories describe functionalities that will be valuable to the user or a system purchaser and have three main aspects:
 
-* Atlassian is a big company, and first hit in Google: <https://www.atlassian.com/agile/project-management/user-stories>
-* The Agile Alliance website has a detailed explanation of user stories and how they are used in Agile development: <https://www.agilealliance.org/glossary/user-stories>
-* The Scrum Alliance has a page with more information on user stories and how they are used in Scrum, a popular Agile framework: <https://resources.scrumalliance.org/Article/anatomy-user-story>
-* Mike Cohn's book "User Stories Applied: For Agile Software Development" is a widely respected resource on user stories and their use in Agile development: <https://finna.fi/Record/3amk.122003> <https://athena.ecs.csus.edu/~buckley/CSc191/User-Stories-Applied-Mike-Cohn.pdf>
-* The Agile Business Consortium has a page with more information on user stories and how they can be used to support Agile development: <https://www.agilebusiness.org/dsdm-project-framework/requirements-and-user-stories.html>
+* A written description of the story for planning and, as a reminder, usually on a note card or index card.
+* Conversations to flesh out the story's details 
+* And tests to convey and document details to help determine if a story is complete or done. 
 
-## What are user stories
+Their representation has prompted a three-C representation of their aspects as cards, conversations, and confirmation or the three Cs. 
 
-User stories are typically used in the Agile software development methodology, which emphasizes rapid and flexible response to change. In Agile development, user stories are used to capture the requirements for a new feature or system. They are used to facilitate the conversation between the development team and the customer or end-user, and help the team understand the desired outcomes and benefits of the feature from the user's perspective.
+The Card represents 2-3 sentences used to describe the story's intent that can be considered an invitation to discussion. The Card serves as a memorable symbol, summarizes the user's intention, and represents a more detailed requirement whose details remain to be determined. It acknowledges that the customer and the team will discover the underlying business/system needed as they work on it through conversation and collaboration around user stories. The Card usually follows a format similar to the one below:
+As a (role) of the product, I can (do action) so that I can obtain (some benefits/value).
 
-In the context of DevOps, user stories can be used to help teams align their development and operations activities with the needs and goals of end-users. By focusing on the user's perspective, teams can ensure that they are building and operating systems that provide value to users and meet their needs.
+Conversation
+The conversation represents a discussion between the target users, team, product owner, and other stakeholders, which is necessary to determine the detailed behavior required to implement the intent. The collaborative discussion is where the story's actual value lies, is facilitated by the Product Owner, and involves all stakeholders and the team. The conversation is primarily verbal but most often supported by documentation and ideally automated tests of various sorts (e.g., Acceptance Tests).  
+
+Confirmation
+Confirmation represents the Acceptance Test, which is how the customer or product owner will confirm that the story is implemented to their satisfaction. The Product Owner must prove that the story is complete before it can be considered "done or complete."
+The team and the Product Owner check each story's "doneness or completeness" in light of the team's current definition of "done."
+Specific acceptance criteria different from the current definition of "done" can be established for individual stories. Still, the current criteria must be well understood and agreed to by the team, and all associated acceptance tests should be in a passing state
 
 ## Functional v. non-functional
 
-Functional user stories are stories that describe a specific function or feature that a system should have. These types of stories focus on what the system should do, and they often include specific details about how the feature should work and what the user should be able to do with it.
+Functional user stories describe a specific function or feature that a system should have. These types of stories focus on what the system should do, and they often include specific details about how the feature should work and what the user should be able to do with it.
+
+Non-functional user stories, on the other hand, describe a system's quality attributes or the constraints under which it must operate. These stories do not describe specific functions or features, but rather they describe how the system should behave or perform in a certain way. Examples of non-functional user stories might include stories describing the system's performance, security, or usability requirements.
+
+The quality of a user story can be tested using the INVEST criteria. The acronym INVEST stands for:
+
+- Independent: User stories should be self-contained in a way that allows them to be released without depending on one another.
+- Negotiable: User stories should mainly capture the essence of the user's need, leaving room for conversation and not be written like a contract.
+- Valuable: User stories should deliver value to the end user.
+- Estimable: User stories should be estimated to be appropriately prioritized and fit into sprints.
+- Small: A user story represents a small chunk of work that enables completion in about 3 to 4 days.
+- Testable: A user story has to be confirmed via pre-written acceptance criteria.
+If the story fails to meet one of these criteria, the team may consider a rewrite (which often translates into physically tearing up the old story card and writing a new one).
+
+## How to make user stories
+User stories aim to capture just the essential elements of a requirement, such as who the requirement is for, what the user expects from the system or the system's goal, and why it is essential or its benefit. Some guides on how to write them include:
+
+- Keep the description of the user story short.
+- Think from the end user's point of view when writing a user story.
+- Requirements are found with the end users, not by the end-user or the development team. 
+- Communication is always important in understanding what the end user wants.
+
+User stories are usually written in the form of:
+
+> "As a `[type of user-who]`, I want `[some goal or desired action-what]` so that `[some reason or benefit-why]`."
+
+The who part denotes or describes the user who interacts with the system, not the developer, and should be as specific as possible. 
+
+The what part denotes a goal written in the active voice as a behavior or action of the system and is usually unique for each story.
 
-Non-functional user stories, on the other hand, describe the quality attributes of a system or the constraints under which it must operate. These stories do not describe specific functions or features, but rather they describe how the system should behave or perform in a certain way. Examples of non-functional user stories might include stories that describe the system's performance requirements, security requirements, or usability requirements.
+The why part denotes a benefit that translates to a real-world result external to the system meaning many stories may share the same benefit for multiple users or customers.
 
-### Examples
+Within software development, the user represents the end-user, the system's goal is usually a new product feature, and the benefit means a targeted product feature.
+
+### Examples of user stories
+Some User Story Examples include:
+
+As a [customer], I want [pricing feature] so that [I can easily purchase items online].
+
+As an [manager], I want to [generate a report] so that [I can understand which departments need more resources].
+
+
+
+
+Here are also some examples to illustrate the difference between functional and non-functional user stories:
 
-Here are some examples to illustrate the difference between functional and non-functional user stories:
 
 Functional user story: 
 > "As _a customer_, I want _to be able to search for products by category_ so that _I can find the products I'm interested in more easily_."
@@ -41,3 +85,15 @@ Functional user story:
 
 Non-functional user story:
 > "As _an administrator_, I want _the system to be secure_ so that _I can be confident that my data is protected_."
+
+
+# Reference
+
+* Clarke, R. J., & Kautz, K. (2014). What's in a user story: IS development methods as communication.
+* Visual Paradigm (2022). What is a user story? https://www.visual-paradigm.com/guide/agile-software-development/what-is-user-story/ 
+* Cohn, M. (2004). User stories applied: For agile software development. Addison-Wesley Professional.
+* <https://www.atlassian.com/agile/project-management/user-stories>
+* The Agile Alliance website has a detailed explanation of user stories and how they are used in Agile development: <https://www.agilealliance.org/glossary/user-stories>
+* The Scrum Alliance has a page with more information on user stories and how they are used in Scrum, a popular Agile framework: <https://resources.scrumalliance.org/Article/anatomy-user-story>
+* Mike Cohn's book "User Stories Applied: For Agile Software Development" is a widely respected resource on user stories and their use in Agile development: <https://finna.fi/Record/3amk.122003> <https://athena.ecs.csus.edu/~buckley/CSc191/User-Stories-Applied-Mike-Cohn.pdf>
+* The Agile Business Consortium has a page with more information on user stories and how they can be used to support Agile development: <https://www.agilebusiness.org/dsdm-project-framework/requirements-and-user-stories.html>