It has been a while since I penned a post. Great User Story writing is an art. Just so I don’t fall into bad habits, a bit of therapeutic* writing can help keep my saw sharpened!
Put the User at the Centre
Our customer is the star of the show. They are the one we want to provide value for so we can, in most cases, send them an invoice for the service.
From the Agile Manifesto Principles, ” Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
When designing the User Story, we must strive to ensure that we complete a fully functioning software deliverable. It is very easy to fall into a component mindset and deliver an element of software that provides little value to the customer. How valuable is supplying only the database for your dating app then asking the customer to write their own search logic to find the love of their life?
Swipe left on that idea…
Why Oh Why
What is motivating the customer to need the feature anyway? Take some time and dig into the needs of the customer. Ask the customer open-ended questions to help bring out their needs and desires. Some examples include:
- How will this feature save you time?
- How will this feature help you connect with others?
- Does the feature help you bring disparate information together in some meaningful way?
- Can you describe the anxiety you have through the week when you think of this unmet need?
- How do you solve the problem today?
Development teams can focus their solutions when they have a clear understanding of the pains the customer is experiencing. The deeper the context we can achieve with the customer’s pains the more focused the resulting solutions will be at solving those pains.
Action Verbs
When describing the specific need of the customer a solid recommendation is to use action verbs around the noun patterns.
What does this really mean?
When solving for the customer pain points, there is always something involved; a noun. For example: payment, bill, claim, job candidate, date (the one on the calendar), date (the one you take to a concert)…
An action verb describes the activity at a single point in time. When a claims adjuster approves your case, they can then pay the claim. During testing, we can check that all the conditions for paying the claim have been met. If so then the claim is paid. A paid claim is:
- Discrete – there is a single instance of the occurrence.
- Independent – a paid claim is not dependent on other paid claims.
- Countable – the instances of paid claims can be tallied.
The opposite of an action verb is the mushy verb. Mushy verbs usually describe a complete lifecycle of an activity and do not form a clear snapshot in time. Manage claim is an example of a mushy verb.
The danger of using mushy verbs in a user story is that the team building the feature will have greater uncertainty on what needs to be done, resulting in higher effort estimates for the story.
Out with the Technical Details
Teams early in their maturity may take a component based approach when creating their User Stories. Product Owners get into a solution mindset or are influenced by their team to take a specific solution path when writing the User Story. This can risk the team framing the wrong problem, leading to a solution that is of limited value to the customer.
To avoid this, the Product Owner can try the following techniques:
- Stories are written in a way that the “What” question is being answered. The team will debate “How” they come up with the solution. Once they settle on a solution path, they will specify the task work needed to get the story to “Done”.
- Write the story and acceptance criteria from the perspective of the customer. An acceptance criteria example can be, “GIVEN that the routing costs require a country to be selected, AND the country must match the routing cost country list, WHEN the customer selects the country, THEN the system will update the routing cost formula to include the cost factor for that country AND display the final routing cost for the customer GIVEN that all other routing cost information has been entered by the customer.
- Articulate Non-Functional Requirements into statements of value for the customer. Articulate the requirement, “The batch job is running too slow, we need to upgrade the ORM so we can process 100,000 records a minute!” to “As the payroll manager, I need the ability to see my payroll summary in under a minute after I submit it so that I can determine if I made a mistake and fix it right away”. With the story framed this way, the team is open to select How they wish to approach the implementation and there is a measure of success given by the customer.
I shall not write component based tasks as user stories.
I shall not write component based tasks as user stories.
I shall not write component based tasks as user stories.
#Principle7 #ValueFirst #UserStories
