Creating tickets/issues
Why is it important to have well thought-out tickets?
As everyone in the team should be able to pick up any ticket from your sprint and start working on it, it's important that the task descriptions are accurate and understandable to everyone who reads them. Creating a task that has a description that is only understandable to the one person who created the task, blocks everyone else from working on it.
User stories
New tasks are often described as user stories. This means they are written from the perspective of the user, to keep the development customer-centric and to also provide background information to the engineers about what the customer wants to do or achieve.
Some examples of user stories:
IN ORDER TO log into the self-service quickly, securely and from whereever I am
AS A company self-service user
I WANT the self-service to offer the option of mobile-ID login
IN ORDER TO be able to add new products into our company's e-store
AS AN e-shop administrator
I WANT the company's e-store administration panel to allow adding a new product
Acceptance criteria
Acceptance criteria is often added to the ticket to summarise what needs to be completed in order to consider the user story or task as "done". Here we often have some additional information that elaborates on the initial user story.
Here is an example of acceptance criteria based on the e-store user story described above
Acceptance criteria
There is a button in the admin panel titled "Add a new product"
Clicking the button leads the e-store admin to a form where parameters of the new product can be entered
The following form has these fields: product name, description, picture, size and quantity
All the fields are mandatory, field validation is in place to alert the user if any field was missed
After filling in the fields, the e-store admin sees a preview of how the product will look in the e-store
The e-store admin can publish the product to be shown in the store
Some of this might seem very obvious and intuitive at first glance, however, it's still important to describe all the requirements in the acceptance criteria to definitely achieve the desired user experience as a result of completing the user story.
Additional information/links
Sometimes it's also relevant to provide some additional links to documentation, resources or refer to work that was completed previously. If needed, add a link to design specification, a third party service's API documentation or a libary that would be good for solving the problem at hand to the task/user story.
Bug reports
When reporting a bug, it's really important to write down the steps needed to reproduce the issue and the configuration used when the bug occurred, such as the browser, device and operating system, as some issues might depend on external factors. It's also important to note which environment the issue occured in - was the application running in your computer, Docker or a server?
Technical tasks
For more technical tasks, for example some setup work, it's not necessary to follow the user story format described above but it's still important to write down a good acceptance criteria and include any links that might be relevant. When creating tickets for your team, it's always better to have more information, rather than less information.