As my last post was about how to write good User Stories, this post is about good structures for them. When developing products that require several team and stakeholders to collaborate, it is beneficial to have a common User Story structure so that everyone can focus on the product instead of struggling with information and requirements about it. With all the points below please remember that a User Story should be a place holder for conversations. So avoid adding all details and take away room for negotiation and conversation.

Most people involved in Agile Software Development are familiar with User Stories which, in it’s slimmest form, consist of a narrative and a small set of acceptance criteria. But what about Epics? What exactly is an epic and how does it distinguish from a user story, theme, initiate, spike or task? Let’s have a look what the purpose of an epic is and what it usually looks like in Agile Software Development.

User Stories and their Acceptance Criteria as the base of implementation work is shown by the example of drawing a house in this post.

User Stories are commonly used in context of Agile software development but that’s not a limitation. Acceptance Criteria will allow you to determine whether or not you have completed the implementation of a User Story.