#ef7e12

What if Descartes were a Product Owner

Cihan Demir // Agile Team Member

Let's do some brain exercises together. Our question is: If the French mathematician and philosopher Rene Descartes had lived today and not in the 17th century, and if he were a Product Owner, how would he write user stories**?

Let me start by defining the user story for those who do not know or have just heard: User story is the writing of the function that the user aims to realize while using the product from his/her own mouth. In other words, it defines the user's needs from his own perspective rather than how to do the targeted thing.

At its most basic, a user story tries to answer the following questions: "Who", "What" and "Why".

We can create a very simple and short template like this: "As <X user>, I want to perform <Y activity>. So I can provide <Z benefit>." Thanks to this template, we can answer the questions “Who”, “What” and “Why” respectively.

Based on our template, we can write the user story as "As the owner of the motor insurance policy, I want to be informed when hail is expected. So, I can protect my vehicle from damage."

In such a case, how can a connection be established between Descartes' problem-solving approach and user story? There is a proverb that can shed light on us. Descartes says, "Divide each difficulty into as many parts as is feasible and necessary to resolve it." Descartes proposes to deal with each difficulty or problem by dividing it into as many parts as possible.

Let's go one step further: if we follow Descartes' suggestion, how can we do the division more methodically?

At this point, the abbreviation INVEST comes to our aid and guides us to write a good, quality user story:

Independent: It should be independent. The lack of dependency on other user stories makes it easy to complete.

Negotiable: It should be negotiable. It should be open to discussion by team members in order to achieve a good result and create value by fulfilling the desired need.

Valuable: It should be able to generate value. The desired feature or function should both add value to the product and create value for the user when completed.

Estimable: It must be able to exert effort. To be prioritized, it must be able to exert effort. If delivery times cannot be estimated, dividing it can help.

Small: It must be small. It must be finished within the relevant sprint or iteration. For example, if 2-week sprints are run, it should be estimated to be completed in 3-4 days at most.

Testable: It must be testable. When the user story is implemented, it must be testable so that it can be set to "complete" status and seen to be finished.

We now have our template (“Who”, “What” and “Why”) and our cross-check method (INVEST) for a good and quality user story. As a team, when you start the day with a good daily, I hope you have excellent user stories that you can talk about and discuss.

P.S. You can contact us by clicking here to share your experiences and ask questions about the agile working method.

*: Product Owner: Responsible for product development. Responsible for the management of the product backlog; sorts and prioritizes the items in the list. It is the voice of the customer.

**: User story: It is the simplest and most understandable explanation of how to do every job in Sprint, a feature to be used by the end user, again by this user.

Comments

Image CAPTCHA
Enter the characters shown in the image.