Microservices are getting very popular these days. This type of software architecture has a lot of advantages like flexibility and ease at scale. Mapping them into small teams in an organization also gives a lot of efficiency in development.
However, going on the adventure of microservices knowing only the benefits is a wrong call: you need to know what you are facing and be prepared for that in advance. You can get a lot of knowledge from many books and articles on the Internet but, when you get hands-on-code, the story changes.
Agile is about being fast and flexible at delivering value, but that doesn’t mean that you shouldn’t care too much about writing User Stories. The description you’ll add to them should not only enable communication and constructive feedback, but also motivate your team. Within this article I’ll try to expose what are the common pitfalls while writing a User Story, and how game designers have understood this before companies so you can apply gamification techniques to it.
There are many articles about this topic: your company/team is working Agile and you notice soon that you miss Architecture… or at least a little bit of software-design-common-sense if you don’t like big words.
I would like to share my view on the problem, and also what I think is a pragmatic solution to deal with this (difficult) Agile & Architecture combination.