Coaching Teams and Stakeholders on User Stories and Tasks (STAR Methodology)
During any project development, much of the frustration, dissatisfaction and rework of the project can be boiled down to one cause — mis-communication. The requirements gathered should always be end-user centric. If each requirement is viewed as per its utility from end-user’s perspective, then it ensures that the implementation is serving the correct audience.
Situation
Sienna is the Scrum Master and she and her team are working on implementing an e-commerce website. They have received a bucket list of requirements from different stakeholders along with lots of recommendations from experts. Sienna understands that taking an end-customer approach for requirement gathering is important as it will ensure that we are always aligned with the project goal.
Task
Now, Sienna’s task is to work with the Stakeholders and Technical team and introduce them to a new way to submit the requirement — User Stories and Tasks.
Action
Sienna has set up a meeting and has created a slide along with a working session to explain how to write User Stories and submit requirements from User’s perspective. The workshop had following major sections:
1. Explanation of User Stories along with examples:
A user-story answers 3 basic questions –
- Who is the user of this feature?
- What is it that the user wants?
- Why do the user want it?
Sienna takes the example of a check-out page in e-commerce website. The answers to above questions will be:
Who -> The Shopper, What -> to checkout, Why -> to buy products
Now, these 3 questions can be arranged in the following format:
As an User Type, I want feature, So I benefit
This format is a User Story!
Taking our check-out page example again, the User Story will be:
As a Shopper, I want to checkout, So I can buy the product.
This format of taking the requirement ensures that everyone is always aligned. User Stories provide the basis of communication in Scrum and is the foundation of the shared understanding.
2. Explanation of Tasks along with Examples:
User Story is the definition of the requirement. To implement the requirement, the User Story is divided into Tasks. Tasks are the smallest part of the implementation and are usually done by one person and the duration is around one day. Taking the example of Check-out page again, the tasks would be:
- Reroute the user to a secure page for entering billing information
- Create routes for billing authentication
- Create DB query for Discount coupon verification
- On checkout, change the order-id to “purchased”
Etc..
All these tasks should have a “Acceptance Criteria”. It means, the task would set to complete, only when the acceptance criteria is met. Eg: for the task — “On checkout, change the order-id to “purchased””, the acceptance criteria would be:
- The product-id is set as ‘sold’ in DB
- The page displays ‘Purchased’
- A delivery method is created for the order-id.
Only when the Acceptance Criteria is met, the task can be set as “Completed”.
Result:
As a result of workshop, both Stakeholders and development team understood the importance of the User Stories and Tasks and how they facilitate a direct connection between the business and technical team. User Stories and Tasks also ensures that the implementation always keeps the big-picture in focus and deliver highest business value in shortest time. The workshop was a success!
