How to write work assignments for developers

Communication with developers might seem hard and threatening, but it doesn’t have to be. You don’t have to shout “scrum” three times while turning in circles before a meeting. You don’t have to choose the right colour of post-it notes that matches the current moon phase and goes well with your kanban board. And you don’t even have to sacrifice five sharpies to the Agile Gods to speak the developers’ language.

Let’s assume that you are an expert in a particular business domain of your company. You could be an accountant, a manufacturer controller or a pricing specialist. And you use a product that is developed by a team of developers in house.

If you are a developer, product owner or somehow part of the dev team use this article to better empathise with your business experts and help them craft astonishing user stories that will be joy to implement.

Purpose of a ticket

In every company there is a different way to communicate and log your needs and requirements, it could be a specialised systems – like JIRA or Trello – or it could be emails or meetings. The tool is not important as the message in it should always be the same.

For simplicity, we will use the word ticket as a tool of communication. It is the message that you need to give the dev team to start the work. So what is the purpose of such a message? It

The most important role of the ticket is to express your business need to other people. Note carefully that I’m not talking about a solution, but about your need. What do you need to solve? Why do you need to solve it? Not how to solve it.

Let’s have a look at a few examples of business needs.

There is an audit next month that focuses on our inventory practices. For that event, we need to explain how many items we have on stock per each day in the year.

Another could look like the following.

At the end of each month I need to send a history of the calls in certain areas from our customers to our partners. At the moment I put it together manually but as our customer base is growing it is more and more time consuming and I need to hire more people to help me with the task.

By stating your need you allow a developer to find the best solution for it. But simple stating might not be enough. You should also provide relevant context. How do you deal with the problem nowadays? What did you try in the past? What are other relevant information relevant to your need? Who else might use it?

The context could be infinite but try to provide at least current state of affairs and any historical attempts to solve it. Other companies could be working in similar area and it might be relevant how they tackle the task in hand.

The more knowledge and context you provide, the more accurate the solution will be delivered and you will make sure that the developer won’t build something that is useless for you.

Lastly, a well-crafted ticket serves as a documentation and could provide context and knowledge for any future pieces of work. It should be treasured more than gold because it contains your companies know-how and knowledge.

What to avoid

There is a few things to avoid in the while writing the ticket and these are

You are the business expert in your domain and you know your need the best. You have to communicate it in your language and not try to translate into a technical programmers’ jargon. There are so many details and misunderstandings that will be lost in translation in this way. And for developers, to provide any decent solution to a problem, they need to understand the problem first and that comes with understanding the domain language. Therefore, developers needs to learn your domain language, terms and processes and you should help them by explaining it.

As you are the expert in your domain, they are experts in finding and implementing solutions. Don’t get me wrong – if you know what might solve your need, go ahead and mention it in the ticket. But make sure that you explained your need first and be prepared that there will be a different solution to your problem. Once again, explain your need first and don’t jump straight into technical solution.

Developers might misunderstand your need at first or they might not understand your language. They will ask questions to get it right, so be prepared to answer them and help them. Software development is an iterative process and there is so many ways how to implement and solve an issue and by working with a quick feedback loop (question – answer) you will come towards better, correct and timely solutions.

Example

Let’s have a look at a good example — Brian that manages relationships with B2B clients has a need and he writes it into a ticket.

Brian:

Every month, I have to send a consumer participation report to our B2B clients that has a list of their active consumers. At the moment we can export the list of all consumers for a particular client from B2B participants page.

We have around 1000 clients and for each I have to generate the report, filter it by the status of the consumer and copy the data to a new sheet and save it which is time consuming.

Brian expressed his business need by using his domain language. Also, he provides additional context about the current state of affairs. Now Rachel is looking into the ticket and tries to suggest a solution, she knows that the dev team is under lots of time constraints and Brian needs to check every report before he sends it so she offers a simple solution first.

Rachel:

As far as I know, we are not using this report for anything else. Maybe I could remove all the consumers that are not participating from the report.

Rachel suggests a solution, but she also proposes an extra change to the system so she gives Brian a chance to provide more feedback and additional context.

Brian:

That would solve my problem, but Dave is using this report to generate internal stats of non-participating consumers.

Now, Rachel has the extra information and she can decide whether she’ll add another report or make the existing one more configurable, but the solution will be spot on in both cases.

Conclusion

You don’t have to fear communication with developers and if you express your business need and provide enough background and context the final product will be better and will make you more productive.

Also, if you buy into the process and provide feedback by answering questions quickly, it will speedup the process and you’ll see the results sooner. Lastly, by using your own domain language you are helping developers to come up with more accurate solution that tightly suits your business.

Would you like to get the most interesting content about programming every Monday?
Sign up to Programming Digest and stay up to date!