Turns out I took well-written tasks for granted for quite a while.
My manager always had well formulated and detailed stories for us. We even didn't start working on it if something was missing, e.g. design or clear product goal.
Writing a good task proved to be not easy when you have to do it yourself.
Check your intuition. Do you feel the difference between those task titles:
bug: approval flow problem
and
Supplier approval buttons are not shown
What does it take to formulate a good issue?
Before we begin: why bother at all?
If somebody doesn't understand the task, they can always ask, aren't they?
Waste of time
Suppose we have 4 relevant people to work on a particular task - product owner, engineer, designer, and QA.
In case the task is not clear, the product owner needs to explain it all over again to all relevant people involved. Now, multiply it by the number of tasks. Thus, the product owner will be busy with clarification over and over around 80% of their time.
Achieving wrong results
Let's continue with our example. 4 people need to communicate with each other. Everybody might understand the goal in a different way if it's not formulated well.
In a week, when development is over, and QA is done, the product owner might realize that certain things were missed. The team will have to spend extra time to fixes.
Understanding the context
When you create a task, you have a context. Of course, it feels that one sentence is enough. The problem is that the context might change in a matter of weeks.
When you have to go back to that task in a week, that one sentence doesn't say a lot. Even worse, it's not clear whether this task is relevant now at all.
Providing the necessary amount of relevant details could solve all those issues above.
Characteristics of tasks
Good feature task
Good feature tasks include the following:
The title states the objective;
Describes a user pain or motivation;
Describe a proposed solution;
Has a clear definition of done (aka QAable).
Good feature tasks do NOT include step-by-step instructions for implementations.
For example, a good task might be formulated like this:
Title: Be able to create recurring order
Problem: There are several requests that can be repeated at a certain amount of time, e.g. every month. Now users have to remember to repeat them without any notifications.
Desired solution: Be able to create request in recurring mode. After the request is approved, new order is created at a specified time period and shown the top of the table. An email notification is sent to the creator.Good bug task
Good bug task has the following:
A title that describes what's wrong;
Clear instructions on how to reproduce the bug;
Clear explanation of what it prevents our users from doing;
Describes the level of severity;
Has corresponding logs if applicable.
Example:
Title: Supplier action buttons are not shown
Steps to reproduce:
1. userX@email.com creates a new supplier
2. userY@email.com receives a notification about new approval
3. Enters the app to approve, no buttons. See the screenshot below.
ScreenshotThe example above might be improved but it contains enough information for the team leader to prioritize this bug. It clearly states what functionality is broken and for whom.
Detailed steps to reproduce include the list of actions as well as user details in case the bug doesn't happen to everyone.
Conclusion
Writing tasks well is a discipline that requires practice. While writing this post, I've explained one of our development tasks to team members and didn't put it in writing. 3 days later my manager saw the result and pointed out that I misunderstood the task and now we need to fix it.
Next time I'll double down on formulating the tasks well, hope, you will too.