How to Successfully Set Tasks and Boost Your Development Team’s Productivity

Written by Nataliia Peterheria — Project Manager at Django Stars.

There’s a saying that goes “Go I know not whither and fetch I know not what” and usually, mostly ironically, this describes a poorly set task — something that we all know too well and had to suffer through more than once. But, after more than three years of working on projects of all levels of complexity, I’ve developed some special organizing skills and an in-depth know-how of working in a team. And, as a result, the development team I work with is ready to work more efficiently than ever.

Pitfalls Of Wrongly Set Tasks

Communication within any team is one of its strongest pillars. The outcomes of the team member’s joint efforts depend on how well they can discuss parts of the process, ideas and suggestions. But the most important is the way the initial tasks are communicated. Clear, transparent tasks are easier to understand, which means that the team can start working sooner and not waste a lot of time asking questions in the process. Also, if everyone understands what their role is, and what part of the product they are developing, it will be easier to put these parts together, when the time comes. On top of it, communicating the value of a certain task or the whole product right away will improve team spirit and motivation.

If you think of the development team as a precious watch, each member is a valuable part. In order for the watch to function properly, all parts should be in their right places, fulfilling their roles. It’s a bit more complicated with people, but the principle is the same. And communication is what helps grease the wheels in the human mechanism. If you set the tasks right, if speak clearly and logically, your watch, I mean, your team will serve you well and loyal for years to come.

The truth is miscommunication in setting tasks is a bigger problem than we thought. According to the Project Management Institute’s data, unsuccessful communication causes one out of five projects to fail.

Causes and Consequences of Miscommunication

Sadly, there are business people, Product Owners or Business Analysts who write tasks for the development teams and don’t even know they have a communication problem. Even experienced business people occasionally fall victim to bureaucracy and extended hierarchy. Sometimes, Product Owners simply don’t play their role to the fullest. Product Owners are supposed to be the link between the business side and the development team. Their main task is to keep all the features requested by the business side in one place and to communicate product requirements to the developers. This, however, doesn’t always happen as it’s supposed to.

If this is the case, two scenarios are possible. Either the Product Owner isn’t even aware of problems in communicating tasks, or this complicated process is the usual way they conduct business.

However, we all have to face the fact that miscommunicated goals can lead to stress and tension within the development team while wrongly or irrationally set tasks often require more effort (and money) to be completed. Which leads to exceeded budgets and broken deadlines (which can also lead to penal fines). And, of course, we waste a lot of time explaining requirements again and again.

Let’s take a closer look at what’s going on. What are the underlying issues that can cause miscommunication between a development team and a client? Most of them can be roughly divided into three sub-issues:

After we’ve identified these three directions, it will be easier to understand what exactly clients can do to become better at setting tasks to the development teams they work with, saving time, money, and energy. Most importantly, remember that where there’s a problem, there’s always a solution.

How to Set Tasks Right

So, what do you do if the development team doesn’t know the ins and outs of the domain they have to work with?

Make a Presentation of the Project

Before launching the development process, begin your cooperation with a presentation of the future product’s set of features. Describe in detail what problem it’s going to solve, as well as its business expectations. Give examples of competitors and set deadlines, if there are any. These can be either the ones promised to the stakeholders, or associated with a professional exhibition.*

*For instance, if there’s a startup exhibition in six months that you definitely want to be part of, let the devs know about it, and set your scope for the development team in advance to leave them enough time to work.

Having this information, the development team can start efficiently working on architectural solutions already in early stages, which can help them understand how much time it will take and what approaches they should use, as well as to see the value their work has for the business.

Provide a Business Roadmap

This will help to define a more reasonable and aligned developmental approach. Most importantly, it will help developers understand the order in which all features have to be realized, how they all work together and what their dependencies are — whether on each other, parallel execution, or on important contracts.*

*If you’re working on anything that requires integration with a Bank, or a payment system for instance, keep in mind that banks are quite bureaucratic, so don’t count on signing all the necessary contracts quickly. And if you’re working on a complex banking service solution, paperwork can significantly affect the deadline.

Find the Common Language

Business language and technical language are different. When collaborating with a development team, what can you do to prevent this from corrupting your communication?

No matter how good the developers are in their field, it may be challenging for them to understand some of the client’s requirements. Especially if they use highly specific terminology from the field the product is going to be used in. As a client of a development company, or a Product Owner working with one, you should keep this in mind and keep it simple. The tasks should be written in a language understandable for everyone. Or, if you feel like there’s no way around such terms, both sides have to stipulate and agree on what vocabulary you’re going to use during the project.

If, after all of this, there are still issues that remain unclear, the development team may send their inquiries to the client. It’s important to keep them clearly formulated and professional, as well as using business terms and phrases like “Did I/we understand it correctly, that…”, or “…to be on the same page”. Under no circumstances should the client feel inferior due to not understanding a technical term. But if both sides find an understanding, and the development team fully understands the client’s business needs, they could even suggest a better approach to fulfilling them. This, however, can only be achieved under the conditions of open and trust-based communication.

Organize Communication

To conclude this part, we recommend keeping all communication in one place. This will help you keep all discussions ordered and easy to find, so nothing will get lost. In this way, if a team member, someone outside the team, or maybe someone new on the project will want to dig in, they will have access to all the information pertaining to the project. Finally, maintaining one source of information on the project will prevent your team from losing data if someone leaves the project and takes all their chats and correspondence with them.

Badly explained tasks are probably the most common problem that puts success at risk, not only in working with or managing (remote) development teams, but in any type of venture. In software development, there’s the notion of Ready for Development. This, essentially, describes an agreement between the development team and the product owner on what a full task description is, so that the team can start working on it.

At this point, we’ve talked a lot about the dont’s so it’s probably time to start talking about the do’s of writing tasks for developers. What’s the correct structure? What does a well-explained and complete task actually look like?

Types of Tasks to Remember for Effective Setting

A task that has structure and focuses on the important is easier to grasp and to realize. Which is why, I think, it’s important for the team to settle on the types and content of tasks they’re going to work with in advance.

In my view, there are three types of tasks: developing new features, bug fixes and investigations. These all have their own distinct features. To maintain a good task structure, focus on these, and on what’s really important.

Many approaches to formulating tasks exist, but their common goal is to describe features in detail and provide valuable information. They usually consist of:

• Title — an on-point, short description of the task that answers the questions What? Where? When?
• Description — the body of the task and the actual set of goals to be reached.
• Bonus! — additions that help understand the description:
• A screenshot with markings concerning the task
• Dependencies and effects on other parts of the application
• A file with stored formulas (if it’s a calculation)
• A clickable prototype to show how to navigate between pages
• A link to a competitor

If you have to report a bug, these tasks require slightly different information. You have to state explicitly what went wrong, where, when, and under which circumstances. To keep it clear and transparent, use these parts:

• Title — this part is the same as with (a) — in short form, you say what happened, where, and when.
• Description. Apart from steps to reproduce, the perfect description contains
• User data of who experienced the bug, and the bug’s environment;
• Тime of the occurrence;
• Additional conditions, typical of this particular application;
• Expected and actual result;
• Links to original requirements, screenshots, etc…

Not all clients realize the importance of a well-written bug report. Consequently, they don’t take the time to write down the steps to reproduce. Sometimes, they simply don’t understand the value of a detailed task, but still get the bug fixed as soon as possible. However, this only leads to the contrary — an insufficiently described bug that ultimately takes ages to get investigated, reproduced, and, finally, fixed. There’s also another problem that may arise when clients don’t realize the importance of the bug’s environment or exact location. This is when clients may report the problematic button by simply sending a screenshot of the button, but not of the whole screen showing the URL, time on the computer screen, etc. This data can increase fixing time substantially. To save everyone’s time, both sides should talk about and agree on the process of reporting bugs in advance.

Spikes are the tasks that have to be investigated. The outcome of a spike is that valuable information is received based on the research conducted. When a client needs to make up their mind about what system to integrate with, a certain analysis should be conducted in order to make an optimal decision. This is why investigation tasks — spikes — exist. Tasks like these result not in lines of code, but in data on which the client can make an informed decision or prepare the next development.

General Recommendations and Tips on Setting Tasks

Like many things in life, tiny little details can make a big difference. Similarly, there are features that will help make a task clearer to everyone, and keep the whole development process transparent and in good order.

• Assignee — the person assigned with the task and responsible for completion. Someone the client can approach with questions concerning this particular part of the process.
• Priority — optimizing the development process through setting task priority and minimizing unnecessary communication. Clients have to decide what feature and what task is more important to them at the given moment.
• Due date — of course, the team must know the time frame assigned to a task — especially if it wasn’t decided or agreed beforehand.

To help all participants see where everyone stands at any given time, it is important to include status updates of every task. We recommend a unified status description — three phases that can be subdivided into substages, if necessary. These will help maintain transparency and give an overall understanding of what is going on:

Stage 1. Working out business requirements.

Stage 2. Development process.

Stage 3. Accepted by the client and deployed.

If you get into detail of these steps, it looks something like this:

When you start a project, you need information on the product. As soon as all the requirements are complete, the task is ready for development. From a task in To Do, you can progress onto the task in review. After it’s been tested, it’s either done and ready for deployment or re-opened for improvement and, only when finished, marked as ready to be deployed.

Communication Is Gold

All this proves that any project requires structured communication and a clear understanding between the client and the realizer, project owner and vendor. Badly explained tasks and vaguely put requirements can put the brakes on any project, substantially delaying product deployment and significantly increasing development costs.

To avoid any possible miscommunication, both sides have to be aware of what the pain points might be in the future and talk them through in advance. By settling on the vocabulary to be used in the project, you can clear up any terms that may cause problems. Finally, it is vital to discuss deadlines and other possible restrictions. On top of all this, there should be a discussed efficient task structure, as well as a way to report bugs within the application. It may seem like nothing, but in the end, this is what will make the experience for both the client and the development team as smooth as possible.