How to Successfully Set Tasks and Boost Your Development Team’s Productivity
Tags: projectmanagement
Published: 2019-03-27 13:58:01

---
title: How to Successfully Set Tasks and Boost Your Development Team’s Productivity
cover_image: https://cdn-images-1.medium.com/max/800/1*wvn4ENkPcWsWrsA1EOwMtA.png
published: true
description: 
tags: project management
canonical_url: https://djangostars.com/blog/successfully-set-tasks-development-team/
---
<span style="color: #333333;">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, <a style="color: #333333;" href="https://djangostars.com/case-studies/molo/">the development team I work with </a>is ready to work more efficiently than ever.</span>
<h2><span style="color: #333333;">Pitfalls Of Wrongly Set Tasks</span></h2>
<span style="color: #333333;">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. <strong>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.</strong> 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, <b>c</b><strong>ommunicating the value of a certain task or the whole product right away will improve team spirit and motivation.</strong></span>

<span style="color: #333333;">If you think of the development team as a precious watch, <a style="color: #333333;" href="https://djangostars.com/blog/form-successful-development-team/">each member is a valuable part.</a> 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. <strong>If you set the tasks right</strong><b>,</b> if speak clearly and logically, your watch, I mean, <strong>your team will serve you well and loyal for years to come. </strong></span>

<span style="color: #333333;">The truth is miscommunication in setting tasks is a bigger problem than we thought. According to the Project Management Institute’s <a style="color: #333333;" href="https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/the-essential-role-of-communications.pdf">data</a>, unsuccessful communication causes one out of five projects to fail.</span>
<h3><span style="color: #333333;">Causes and Consequences of Miscommunication</span></h3>
<span style="color: #333333;">Sadly, <strong>there are business people</strong>, Product Owners or Business Analysts <strong>who write tasks for the development teams and don’t even know they have a communication problem.</strong> Even experienced business people occasionally fall victim to bureaucracy and extended hierarchy. <strong>Sometimes, Product Owners simply don’t play their role to the fullest.</strong> 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.</span>

<span style="color: #333333;">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.</span>

<span style="color: #333333;">However, we all have to face the fact that <strong>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.</strong> 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.</span>

<span style="color: #333333;">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:</span>

<img class="alignnone size-full wp-image-767" src="https://djangostars.com/blog/uploads/2019/02/IMG_1-14.png" alt="client and vendor miscommunication" width="1765" height="1627" />

<span style="color: #333333;">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.</span>
<h2><span style="color: #333333;">How to Set Tasks Right</span></h2>
<span style="color: #333333;">So, what do you do if <em><strong>the development team doesn’t know the ins and outs of the domain</strong></em> they have to work with?</span>

<img class="alignnone size-full wp-image-766" src="https://djangostars.com/blog/uploads/2019/02/IMG_2-11.png" alt="Common Issues" width="1600" height="1088" />
<h3><span style="color: #333333;">Make a Presentation of the Project</span></h3>
<span style="color: #333333;">Before launching the development process, <strong>begin your cooperation with a presentation</strong> of the future product’s set of features. Describe in detail what problem it’s going to solve, as well as its business expectations. <strong>Give examples of competitors and set deadlines</strong>, if there are any. These can be either the ones promised to the stakeholders, or associated with a professional exhibition.*</span>
<p style="padding-left: 60px;"><span style="color: #333333;"><em>*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.</em></span></p>
<span style="color: #333333;">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.</span>
<h3><span style="color: #333333;">Provide a Business Roadmap</span></h3>
<span style="color: #333333;">This will help to define a more reasonable and aligned developmental approach. Most importantly, it will help developers <strong>understand the order</strong> 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.*</span>
<p style="padding-left: 60px;"><span style="color: #333333;">*<em>If you’re working on anything that requires integration with a</em> <em>Bank</em>,<em> 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.</em></span></p>
<img class="alignnone size-full wp-image-763" src="https://djangostars.com/blog/uploads/2019/02/IMG_3-12.png" alt="Critical path of the project" width="2444" height="1520" />
<h3><span style="color: #333333;">Find the Common Language</span></h3>
<span style="color: #333333;"><strong>Business language and technical language are different.</strong> When collaborating with a development team, what can you do to prevent this from corrupting your communication?</span>

<img class="alignnone size-full wp-image-764" src="https://djangostars.com/blog/uploads/2019/02/IMG_4-11.png" alt="language collaboration" width="1488" height="872" />

<span style="color: #333333;">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 <strong>highly specific terminology from the field the product is going to be used in.</strong> 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.</span>

<span style="color: #333333;">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 <strong>clearly formulated and professional</strong><b>,</b> 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.</span>
<h3><span style="color: #333333;">Organize Communication</span></h3>
<span style="color: #333333;">To conclude this part, we recommend <strong>keeping all communication in one place.</strong> 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 <strong>access to all the information pertaining to the project.</strong> 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.</span>

<span style="color: #333333;">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.</span>

<img class="alignnone size-full wp-image-742" src="https://djangostars.com/blog/uploads/2019/02/IMG_5-7.png" alt="to-do list" width="1600" height="1088" />

<span style="color: #333333;">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?</span>
<h2><span style="color: #333333;">Types of Tasks to Remember for Effective Setting</span></h2>
<span style="color: #333333;"><strong>A task that has structure and focuses on the important is easier to grasp and to realize.</strong> 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.</span>

<span style="color: #333333;">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.</span>

<span style="color: #333333;">Many approaches to formulating tasks exist, but their common goal is to <strong>describe features in detail and provide valuable information.</strong> They usually consist of:</span>
<ul>
 	<li><span style="color: #333333;">Title – an on-point, short description of the task that answers the questions What? Where? When?</span></li>
 	<li><span style="color: #333333;">Description – the body of the task and the actual set of goals to be reached.</span></li>
 	<li><span style="color: #333333;"><i>Bonus!</i> – additions that help understand the description:</span>
<ul>
 	<li style="font-weight: 400;"><span style="color: #333333;">A screenshot with markings concerning the task</span></li>
 	<li style="font-weight: 400;"><span style="color: #333333;">Dependencies and effects on other parts of the application</span></li>
 	<li style="font-weight: 400;"><span style="color: #333333;">A file with stored formulas (if it’s a calculation)</span></li>
 	<li style="font-weight: 400;"><span style="color: #333333;">A clickable prototype to show how to navigate between pages</span></li>
 	<li style="font-weight: 400;"><span style="color: #333333;">A link to a competitor</span></li>
</ul>
</li>
</ul>
<span style="color: #333333;"><strong>If you have to report a bug</strong>, 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:</span>
<ul>
 	<li><span style="color: #333333;">Title – this part is the same as with (a) – in short form, you say what happened, where, and when.</span></li>
 	<li><span style="color: #333333;">Description. Apart from steps to reproduce, the perfect description contains</span></li>
 	<li><span style="font-weight: 400; color: #333333;">User data of who experienced the bug, and the bug’s environment;</span></li>
 	<li><span style="color: #333333;">Т<span style="font-weight: 400;">ime of the occurrence;</span></span></li>
 	<li><span style="color: #333333;">A<span style="font-weight: 400;">dditional conditions, typical of this particular application;</span></span></li>
 	<li><span style="color: #333333;">E<span style="font-weight: 400;">xpected and actual result;</span></span></li>
 	<li><span style="color: #333333;">L<span style="font-weight: 400;">inks to original requirements, screenshots, etc...</span></span></li>
</ul>
</li>
</ul>
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.

<span style="color: #333333;"><strong>Spikes are the tasks that have to be investigated.</strong> 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.</span>
<h2><span style="color: #333333;">General Recommendations and Tips on Setting Tasks</span></h2>
<span style="color: #333333;">Like many things in life, tiny little details can make a big difference. Similarly, <strong>there are features that will help make a task clearer to everyone</strong>, and keep the whole development process transparent and in good order.</span>

<span style="color: #333333;"><img class="alignnone size-full wp-image-741" src="https://djangostars.com/blog/uploads/2019/02/IMG_6-6.png" alt="Tips on Setting Tasks" width="1600" height="1088" /></span>
<ol>
 	<li><span style="color: #333333;"><strong>Assignee</strong> – the person assigned with the task and responsible for completion. Someone the client can approach with questions concerning this particular part of the process.</span></li>
 	<li><span style="color: #333333;"><strong>Priority</strong> – 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.</span></li>
 	<li><span style="color: #333333;"><strong>Due date</strong> – of course, the team must know the time frame assigned to a task - especially if it wasn’t decided or agreed beforehand.</span></li>
</ol>
<span style="color: #333333;"><strong>To help all participants see where everyone stands at any given time, it is important to include status updates of every task.</strong> 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:</span>
<p style="padding-left: 30px;"><span style="color: #333333;"><strong>Stage 1.</strong> Working out business requirements.</span></p>
<p style="padding-left: 30px;"><span style="color: #333333;"><strong>Stage 2.</strong> Development process.</span></p>
<p style="padding-left: 30px;"><span style="color: #333333;"><strong>Stage 3.</strong> Accepted by the client and deployed.</span></p>
<span style="color: #333333;">If you get into detail of these steps, it looks something like this:</span>

<img class="alignnone size-full wp-image-740" src="https://djangostars.com/blog/uploads/2019/02/IMG_7-4.png" alt="status description" width="1765" height="1789" />

<span style="color: #333333;">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.</span>
<h2><span style="color: #333333;">Communication Is Gold</span></h2>
<span style="color: #333333;">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.</span>

<span style="color: #333333;"><strong>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.</strong> 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.</span>

*Written by Nataliia Peterheria — Project Manager at [Django Stars](https://djangostars.com/blog/). Read the original version on [Django Stars blog](https://djangostars.com/blog/successfully-set-tasks-development-team/).*