LevelUp Build Week 1 - Story writing
This weeks agenda:
| Time | Activity | |
|---|---|---|
| 1800 | Arrival & Food | |
| 1815 | Story writing (ALL students) | |
| Developers | BA & XD | |
| 1845 | Development setup | Adv. story writing |
| TDD Session | Epic breakdown with PO's | |
| 2045 | RETROs (in teams) | |
| 2100 | Close and clean | |
After eating some asian food, we were given a short refresher presentation on story making, covering the story lifecycle with an emphasis on the backlog and analysis phase. To understand the concepts clearly, we were given a scenario for which we would need to practice our newfound story writing skills.
Every 2 years, the laptops given to ThoughtWork employees (henceforth ThoughtWorkers) are replaced with updated models. The TechOps sell the older models to the highest bidding ThoughtWorkers. The entire process is currently email based so it is not only slow and error prone but ThoughtWorkers uninterested in buying get notified. TechOps want a web application similar to eBay that would allow ThoughtWorkers to buy and sell laptops to the highest bidder.
We were asked to split into teams of 3 consisting of at least one dev and a business analyst (BA) or experience designer (XD) and given 5 x 3 inch cards, to write stories that would fulfil some of the TechOps requirements.
A story is a description of a feature that takes on the form
As a role
I want requirement
So that reason/ROI
Eg. As a TechOps, I want to see a list of laptops with pictures next to them so that I can determine the condition for the laptop before making a bid.
After 5 minutes, every team was encouraged to share their stories to the rest of the group and we discussed whether some were more suited to being an epic - a broader story encompassing more than 1 self contained feature - and the granularity of the story - should the story specify that a database is used?
At 6:45, the XDs and BAs relocated and the story wall whiteboards were wheeled from the board room into the lobby near the lifts. We were told to be as quiet as possible as people were still working in the office.
Without a projector to see the slides, the coach taught us the basics on acceptance criteria and spiking. We split into pairs and practiced writing acceptance criteria using our stories from the previous exercise. Acceptance criteria are a set of requirements to complete a card that are often, but not always, of the form
Given pre-condition
When trigger
Then outcome
Acceptance criteria can be categorised in three ways: the happy, alternative and sad path. The happy path specifies the traditional use case such as when a user logs into their bank account, a list of accounts appears. An alternative path could be when the user logs in, no accounts are listed while a sad path is when the user logs in, an error message explains their account information couldn’t be retrieved.
The last activity for the night was Epic breakdown with Product Owner and involved everyone going back to their respective teams to begin writing epics and acceptance criteria for their team project. Joining us were the head coach, product owner Rujia and two floating coaches. We found out Team Blue is now Team Ghost.
An epic is a large story that can be split into smaller stories. At project inception, we start with information about the requirements that the product owner wants and as conversations go in depth about a particular story, more details surface.
For example, As a Formula 1 game player, I want an options screen so that I can choose the driver I want to use. Later on, another story emerges. As a Formula 1 game player, I want an image area of a driver so that I can see the driver I want to use. This means the original story would become: As a Formula 1 game player, I want an options menu so that I can choose the driver I want to use.
Our team decided the epics would be similar to the main menu items that were identified during storyboarding at the kick off event:
- Emergency - send a message to an emergency contact urgently
- Services - health, councilling hotline
- Distractions - pacman game, jokes
- Settings - update user info
- Discreetness - the watch does not reveal anything about alcohol addiction in it’s default operating mode
Each epic was further broken down into smaller stories as expanded upon above.
The PO prioritised these stories:
- emergency contact
- telling a joke
- the watch face should not reveal alcohol addiction when the user is not interacting with it
- a list of meetings/clinics within 20 km driving distance
Once we had the acceptance criteria formulated, our first ever team project analysis was complete.