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, is ready to work more efficiently than ever. the development team I work with 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. 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, 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. 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, 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 speak clearly and logically, your watch, I mean, each member is a valuable part. If you set the tasks right, 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 , unsuccessful communication causes one out of five projects to fail. data Causes and Consequences of Miscommunication Sadly, , Product Owners or Business Analysts Even experienced business people occasionally fall victim to bureaucracy and extended hierarchy. 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. there are business people who write tasks for the development teams and don’t even know they have a communication problem. Sometimes, Product Owners simply don’t play their role to the fullest. 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 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. 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. 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 they have to work with? the development team doesn’t know the ins and outs of the domain Make a Presentation of the Project Before launching the development process, of the future product’s set of features. Describe in detail what problem it’s going to solve, as well as its business expectations. , if there are any. These can be either the ones promised to the stakeholders, or associated with a professional exhibition.* begin your cooperation with a presentation Give examples of competitors and set deadlines *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 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.* understand the order * , 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 When collaborating with a development team, what can you do to prevent this from corrupting your communication? Business language and technical language are different. 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 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. highly specific terminology from the field the product is going to be used in. 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 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. clearly formulated and professional, Organize Communication To conclude this part, we recommend 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 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. keeping all communication in one place. access to all the information pertaining to the project. 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 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. A task that has structure and focuses on the important is easier to grasp and to realize. 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 They usually consist of: describe features in detail and provide valuable information. 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. — additions that help understand the description: Bonus! 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 , 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: If you have to report a bug 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. 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. Spikes are the tasks that have to be investigated. General Recommendations and Tips on Setting Tasks Like many things in life, tiny little details can make a big difference. Similarly, , and keep the whole development process transparent and in good order. there are features that will help make a task clearer to everyone — the person assigned with the task and responsible for completion. Someone the client can approach with questions concerning this particular part of the process. Assignee — 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. Priority — of course, the team must know the time frame assigned to a task — especially if it wasn’t decided or agreed beforehand. Due date 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: To help all participants see where everyone stands at any given time, it is important to include status updates of every task. Working out business requirements. Stage 1. Development process. Stage 2. Accepted by the client and deployed. Stage 3. 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. 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. 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.

Fetch

Read My Stories

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

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

Too Long; Didn't Read

Company Mentioned

Django Stars

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

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

Too Long; Didn't Read

Company Mentioned

Django Stars

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES