User stories are the currency Product Managers use to turn architecture into code. To design any system you need both technical and user-driven stories. Both styles have a place in a app modernization engagement.
Classic stories are written from the users perspective and explain incremental business or user value. Technical stories sometimes may not have an obvious human user and/or a clear business / user value. That is OK.
Sample Technical Story
Title
[driver] service subscribes to [order-accepted] event and publishes [driver-assigned] event with dummy driver information
Classic stories are written from the users perspective and explain incremental business or user value. Technical stories sometimes may not have an obvious human user and/or a clear business / user value. That is OK.
Here are some tips on how to write good stories
- Event Driven Architecture lends well to Gherkin style stories https://www.pivotaltracker.com/blog/principles-of-effective-story-writing-the-pivotal-labs-way and https://content.pivotal.io/blog/how-to-write-well-formed-user-stories
- Techical Story Writing https://medium.com/product-labs/ways-to-approach-technical-story-writing-961e0506fa13
- How To Write Well Formed Stories https://content.pivotal.io/blog/how-to-write-well-formed-user-stories
- Good reference for story writing https://www.pivotaltracker.com/blog/principles-of-effective-story-writing-the-pivotal-labs-way
- When working with non-engineering PMs This is excellent guidance for writing API user stories https://content.pivotal.io/product-managers/designing-developing-an-api-product-part-3-of-4 and https://builttoadapt.io/what-my-backend-and-api-user-stories-look-like-c5e965beb778#.vi9fi0yq4
- A really good overview of different story types, including bug reports, with examples: https://www.pivotaltracker.com/blog/principles-of-effective-story-writing-the-pivotal-labs-way
Sample Technical Story
Title
[driver] service subscribes to [order-accepted] event and publishes [driver-assigned] event with dummy driver information
Acceptance Criteria
When [order-accepted] event is received by [driver] service
Then [driver] service publishes a [driver-assigned] event with dummy driver information
And [driver-assigned] event contains the same orderId that was received from [order-accepted] event
Dev Notes
- The [order-accepted] event will look like { "orderId":"...", "restaurantId":"...", "eventDate":"2019-08-16T15:30:30Z" }
- The [driver-assigned] event might look like { "orderId":"...", "driverId":"...", "eventDate":"2019-08-16T15:30:30Z" }