diff --git a/_data/authors.yml b/_data/authors.yml index ff7ba9c908..ac6f633001 100644 --- a/_data/authors.yml +++ b/_data/authors.yml @@ -101,6 +101,7 @@ active-authors: - slinsley - smartin - smendis-scottlogic + - snandal - ssibanda - swoods - tclarke-scottlogic @@ -699,6 +700,10 @@ authors: name: Stephen Linsley picture: picture.jpg author-summary: '

Marketing Channels Coordinator at Scott Logic, with a background in SaaS marketing.

' + snandal: + name: 'Shikha Nandal' + picture: picture.jpg + author-summary: 'Senior Test Engineer at Scott Logic' sobrien: name: "Siobhan O'Brien" author-summary: 'UX Designer' diff --git a/_data/related.yml b/_data/related.yml index 5ac4ff8841..6337ae8a7c 100644 --- a/_data/related.yml +++ b/_data/related.yml @@ -2443,3 +2443,6 @@ /26/08/2014/StrongTypingWithAngularJS.html: - /02/06/2015/StrongTypingWithKnockoutJSAndRequireJS.html - /2014/08/08/signalr-typed.html +/2023/09/11/the-power-of-a-well-written-user-story.html: + - /2014/09/18/the-agile-mindset.html + - /2014/08/11/a-piecemeal-approach-to-introducing-agile.html diff --git a/_posts/2023-09-11-the-power-of-a-well-written-user-story.md b/_posts/2023-09-11-the-power-of-a-well-written-user-story.md new file mode 100644 index 0000000000..2878dc96d7 --- /dev/null +++ b/_posts/2023-09-11-the-power-of-a-well-written-user-story.md @@ -0,0 +1,69 @@ +--- +title: The Power of a Well Written User Story - A Test Engineer's Perspective +date: 2023-09-11 14:00:00 Z +categories: +- Testing +tags: +- testing +summary: User stories are a pivotal component of Agile Software Development, serving as concise and user-centric descriptions of desired software functionality. Hence, here I am, discussing how crucial it is to put user stories right for setting the foundation for a well-structured, user-focused, and efficient development process. +author: snandal +--- + +At the heart of our modern software development process, lies the humble yet powerful concept of **"User Stories"** - the simplest way to capture what a user needs. *User Stories* serve as the bridge between the business stakeholders and the development team, providing a shared understanding of what the software should achieve. + +Over the last decade, as I worked on multiple projects, there has been one very common challenge that I faced almost everywhere. And that is - Despite having such a vital role in delivering high-quality software products, so little emphasis is given to putting the *User Stories* right. + +Thus, I would like to discuss the importance of logging adequate and accurate information in *User Stories* and its potential impact on the success of software projects. + +*User Stories* are the building blocks that transform user needs into Functional Software by : + +### Ensuring User-Centric Approach +*User Stories* keep the focus on the end user, ensuring that features developed align with real user needs and goals. A well-written *User Story* provides a clear understanding of what needs to be built and why. It outlines the user's needs, the context of the functionality, and the expected outcome. Information logged in the *User Story* helps the team grasp the scope and objectives, reducing the chances of misinterpretations, ensuring that the development efforts align with customer requirements and expectations. + +### Promoting Collaboration and Communication +Adequate information in *User Stories* fosters collaboration between the team and other stakeholders. It promotes discussions and clarifications, ensuring that everyone is aligned with the requirements and the expected outcome, and hence directly impacts the end product's quality and alignment with customer needs, which eventually leads to better understood and met user expectations. + +### Quality Assurance +When it comes to testing, *User Stories* act as a foundation for test planning. Accurate information in the user story enables the test engineer to identify the necessary testing approaches and develop appropriate test strategies. It aids in determining the testing scope, risk areas, testing priorities, and helps the test engineer ensure comprehensive test coverage by understanding the user's expectations. + +## Why Does it Impact Test Engineers in Particular? +While Agile methodologies offer opportunities for test engineer to continuously improve and collaborate closely with the team, these also bring their own set of challenges. + +With continuously evolving requirements, there always stands a need for quick adaptability. +Also, in many places, the *User Stories* are collectively estimated; however, no matter how much we stress allocating sufficient time for testing activities or ensure earliest start for the same, majority time is consumed in building the functionality, and lots of things are pushed to test engineers last minute, adding an immense amount of pressure. + +Not having the latest information readily available in this continuously changing and stressful environment would unnecessarily slow down the delivery and could also have an impact on the overall quality of the product. Hence it is extremely important from a test engineer point of view that all necessary information is carefully recorded and available as part of the *User Story*. + +It is true that Agile values working software over comprehensive documentation, but it does not mean documentation is completely disregarded. Agile does promote "just enough" documentation, which means creating the necessary documentation to support the development process without excessive overhead. And that makes it even more important that adequate and accurate information is captured as part of the *User Stories* and also updated regularly (as required). + +## Essentials in any User Story +Below are the essential components that make up a robust *User Story*, ensuring a shared understanding and smooth development process. + +**Description:** The purpose of the *User Story* clearly stated in simple and concise language, including - the user role or persona it pertains to, the actions while interacting with the system, the benefit or value added - why the user wants to perform this action and how it contributes to their overall experience. + +A *User Story* typically follows a straightforward template: + +"As a [type of user], I want [an action] so that [benefit or value]." + +For instance: "As a *registered user*, I want to *reset my password* so that *I can regain access to my account*." + +**Dependencies:** Any assumptions or dependencies that could impact the development and testing of the *User Story*, such as other *User Stories*, any external factors. Noting these down helps ensure that everyone is aware of potential hurdles and can plan accordingly. + +**Business Rules:** Any specific business rules or constraints that must be adhered to. + +**Acceptance Criteria:** The conditions that must be met for the functionality to be considered working as expected. + +These criterias must be specific and measurable, including both functional and non-functional requirements along with usability or accessibility requirements (as applicable). Include attachments and examples (where applicable), mockups or reference links to provide visual context for the *User Story*. Visual aids help align everyone's understanding of the feature's appearance and behavior. + +**Size or Estimation:** Rough, collectively agreed-upon estimation of the effort required to implement the *User Story*. + +**Definition of Done:** The conditions that must be met for the *User Story* to be considered complete, including aspects of design, testing, and documentation. + +**Acceptance Sign-Off:** People/Team who will approve the acceptance criteria and sign off on the completion of the *User Story*. + + +Additionally, it is important to keep the *User Story* updated with any significant changes in any of the above components. + +An efficient way of making sure that the *User Stories* do not miss any important information is to use an internally agreed upon *User Story* template. Not Every *User Story* would need each one of the above components; however, having added these in the template would act as a checklist and ensure that the information will not me missed. + +**As a test engineer, it is important to understand the critical role that *User Stories* play in guiding the testing process and ensuring the delivery of high-quality software. And hence we need to ensure that each *User Story* is capable of not only meeting its acceptance criteria but also contributing to the overall excellence of the product.** \ No newline at end of file diff --git a/snandal/atom.xml b/snandal/atom.xml new file mode 100644 index 0000000000..0f107742c4 --- /dev/null +++ b/snandal/atom.xml @@ -0,0 +1,5 @@ +--- +author: snandal +layout: atom_feed +--- + diff --git a/snandal/feed.xml b/snandal/feed.xml new file mode 100644 index 0000000000..284fdff1ff --- /dev/null +++ b/snandal/feed.xml @@ -0,0 +1,5 @@ +--- +author: snandal +layout: rss_feed +--- + diff --git a/snandal/index.html b/snandal/index.html new file mode 100644 index 0000000000..7d440dc245 --- /dev/null +++ b/snandal/index.html @@ -0,0 +1,6 @@ +--- +title: Shikha Nandal +author: snandal +layout: default_author +--- + diff --git a/snandal/picture.jpg b/snandal/picture.jpg new file mode 100644 index 0000000000..872dfc8e8b Binary files /dev/null and b/snandal/picture.jpg differ