on
MicroServices and Traceability
MicroServices and Traceability
Tracing Features across Services
Thanks Shashwat.
In my humble opinion, Front-End, Back-End and Schema changes are sub-tasks and do not represent stories. User stories should always be about communicating business value and not a tool for splitting work according to team structure. It may help to organise as Full-Stack teams rather than Front-End, Back-End and Database teams.
With regard to traceability nothing changes when you write user-centric stories. User-centric stories only provide the business context to every Engineer involved in development.
I usually draw high level architecture diagrams with stories marked on them to will give a visual representation of dependencies. Sometimes I resort to old school Gantt charts to provide visibility on timelines. A single story may involve several subtasks, each of which may be owned several specialists.
In my experience, starting with schema design or APIs has very often led to re-work because it is hard to predict needs of UI in isolation.
My preferred approach is to start with the UI and work backwards to the APIs and schema. In a Micro-Services architecture, I stick with the same routine tracing a requirement across several services all.
Example: Booking a ticket
- UX screen mockups
- UI/Front-End Engineers analyse the information required to render the screen and the parameters that will be submitted to the API.
- API/Back-End Engineers take this information and design their API. In the process they analyse the information they will need from systems they depend on.
Hope this helps.
Originally published on Medium on August 5, 2018.