How to write an agile ticket

When you start working agile, you quickly realize that it is important to create value for end users and stakeholders. The tickets are an important part of this, because it describes what value the product brings to users. You can find out what agile is all about in our blog post Agile Software Development. Here we show you how to write an agile ticket:

user story

A user story is the smallest element of a use case and describes in concrete terms the smallest possible task, what the user should do with the creating system and how it should react. You should formulate the user story in everyday language and kept as short as possible:

• Be precise
• Be clear – explain so that others can understand your task
• Describe only one task per user story
• A user story must be independent
• you need to discuss the user stories with customers and developers and adapted decisions and questions
• A user story must be manageable so that the developers can make these assessments
• A complete implementation should take at least 4 hours and a maximum of 80 hours
• User stories must be testable
• You need to divide dependent stories into epics and independent user stories (e.g. user can log in via Facebook)

A User Story should contain the following points:

• An ID number that is the same as in the product backlog and that is assigned by the product owner when he adds an entry to the product backlog
• A short title
• A User description
• What the User wants to achieve
• The reason why the user wants to perform the task

Example: As a website operator, I want users to be able to buy my products online so that I can generate more sales.

As you see, you need to formulate each User Story from the first-person perspective: If I do this, I get this.
Using the first person puts the author in the position of the user or customer.

epics

Epics are feature-level tasks that involve many user stories. The following applies:

• An epic can include multiple components
• Epics usually run over several sprints
• Epics can be expanded with user stories at any time

An epic comprises several user stories about different user roles and scenarios.

Example:

Epic name:Landingpage X
Summary:Implementation of a possibility to manage article layouts in the backend.
Description:Users should be able to manage article layouts in the backend.

writing bugs

If you describe the messages exactly they can be corrected more quickly. The bugs need to:

• Be precise
• Be clear – explain so that others can understand your bug
• Describe only one bug per message
• No bug is too trivial to be reported – small bugs might hide bigger bugs
• Clearly separate facts from assumptions
• Write the bug report – if possible – in English

A good abstract should describe a bug report quickly and unmistakably. You should explain the problem, not your proposed solution.

Example:“Cancelling a File Copy dialog crashes File Manager” or “Down-arrow scrolling doesn’t work in <textarea> styled with overflow:hidden”