The adventure of a user story in Scrum methodology

Introduction

In this reflective journal, based on scrum methodology, I intend to use as an example to illustrate the process that a story goes through from the time it is presented as a new idea or requirement to the time the development team begins to implement it (Rana, 2021).

1.???Scenario description:

Suppose we want to add a new feature to a website that allows you to edit and add animal photos to share on social media.

• The leading service includes features that allow users to add kittens' photos to their social media profile photos.
• Customers can benefit from more advanced features to edit and select their desired photos for a fee.

?2.???Scrum team members:

The team for this project includes six development engineers, a product owner, and a scrum master.

• In addition to the central team, a designer from the design team works exclusively with the product owner.
• Two quality control engineers and a small DevOps team are also collaborating on the project.

?3.???Changing customer and market needs:

Need to change:

The marketing department concludes that the website should also address photos of other animals due to expanding the business market.

• Customers want to be able to use baby rabbit photos in this service as well.
• The product owner realizes the new needs of customers through his interaction with the marketing department. In these interactions, the possible challenges and risks of launching this new service are discussed.

4.???Product backlog change:

The product owner concludes that developing a new service is highly prioritized and should be considered more elevated than the services already in the product backlog.

After a few days of researching and gathering details, the product owner finally concludes that given the past priorities and purpose of the service, the best approach to launching a new service is to ask the development team for a minimal service, which is precisely the same as the existing service functions and run in parallel with the name of the baby rabbit service.

Before proceeding, the product owner talks to the development team engineers to ensure this is technically the fastest way to implement the new service.

5.???New service definition:

After reviewing the new service idea prototypes, the product owner determines the best, most efficient, and fastest way to implement the new service based on the feedback he received from website users.

After that, the product owner decides to serve this new version on a limited basis and only to some users to evaluate the system performance feedback.

6.???Write stories:

After coordinating with the development and the design team, the product owner tries to write the new service stories so that the development team can complete them in a two-week sprint. The product owner does not interfere in breaking this new service into smaller and different parts and leaves this responsibility to the engineers of the development team. Instead, the product owner tries to look at these new features from the customer's point of view.

6.1 The product owner wrote the story for the new service:

As a logged-in user connected to the beta version of the new service, I want to see specific options related to the Rabbit service during the photo upload process. Therefore, by adding the Rabbit baby photo to my social pages, I can share them with my contacts.

6.2 Acceptance criteria:

• First criterion:

A user is assumed to be accidentally (5%) or explicitly connected to the service when viewing the content creation pages. An alert window should be displayed to inform the user that the current version is a beta version.

• The second criterion:

Assuming the user has logged in, he has not selected the option to use the baby rabbit photo. When creating content, creation pages must see standard service without any sign of new service.

?7.???Estimating stories:

After presenting new stories at the planning event, the product owner asks everyone present at the meeting to comment on the stories. In this meeting, the engineers of the development team and the product owner often discuss the issue.

For example, one of the development team engineers says, why can't a new service be added to the existing service in the form of a new possibility? And another engineer believes that integrating this new feature could complicate the data model. The product owner responds that this is just a limited test that only certain users are redirected to the new site with the previous intention. It is also expected that users will be shown a warning message to avoid confusion.

This type of two-way conversation will continue until all members are convinced.

When development team engineers do not sufficiently understand the story, the product owner usually tries to persuade the engineers to accept the stories by determining the scope of the impact. This process may correct stories or acceptance criteria during the Q&A between engineers and the product owner. After making possible corrections to the stories and acceptance criteria, Scrum Master asks all members to agree. If all team members agree with the stories, the story estimation process (estimating effort required) begins.

?8.???Agreement on sprint backlog:

After prioritizing and estimating stories, Scrum Master ensures that team members agree to the terms and that the product owner is satisfied with the addition of the new product service. In this scenario, the product owner has provided only one story for the newsprint. Therefore, the remaining three stories from the previous sprint and the new one will be completed in the newsprint.

References

Rana, V. (2021, March 15). Scrum Agile Methodology: When and Why Should You Choose It? 360 Degree Techno soft. https://www.360technosoft.com/blog/scrum-agile-methodology-when-and-why-should-you-choose-it