I help our CTOs, Development Leads, Product Owners and business executives to design and build scalable and maintainable systems. With over 13 years of experience gained on software development projects delivered to international clients, I am able to enhance the productivity of software development teams while creating data collection, processing and analysis tools.

Błażej Kosmowski

My diverse educational background allows me to approach software development problems from different sides and angles. I have bachelor degrees in Sociology and IT in Business. I am an agile Team Leader and Project Manager. Sport and Combat training allowed me to learn that success comes with hard work. Along came the self-improvement, loyalty, discipline and self-control.

**ABOUT MY TEAM** “...there is no **I** in **Team**”

My Team has an in-depth and long term experience (**4 years** on average) and currently consists of **9 members**. We specialize in **Ruby on Rails**, **React.js**, **React Native** and **Node.js**. We work from **one** **office** which guarantees close and **successful** **cooperation**. We use the following communication tools: Slack, Pivotal Tracker, Trello, Jira and Google Hangouts.

***"With few exceptions the best players are the hardest workers"***

I love coding and I **enjoy** **solving** **various** **business** **problems** with my programming skills.

I am a Head of Production who is passionate about crafting state-of-the-art functional software solutions. In the over 12 years of my professional career, I gained experience in building various types of platforms, which now allows me to mentor my colleagues and share my team-building and technology insights in blog publications.

Ireneusz Skrobiś

I am an agile Team Leader, Project Manager, and testing advocate supporting other developers. Having optimization and scalability in mind, I have led software teams for over 11 years in the end-to-end project development lifecycle, e.g., architecture design, code, and documentation review. I specialize in creating eHealthcare solutions that meet HIPPA requirements. 

Szymon Kieloch

\[TOC\]

The implementation of every new feature or change (hopefully) begins with reading some sort of specification, expectations description, investigating mockups, research etc. If the quality of this step is poor, the tasks delivered might not fulfil the product owner’s expectations and/or may be delivered later rather than sooner. On the other hand, if appropriate measures are taken to provide high-quality task descriptions, such tasks will most likely be handled efficiently, accurately and on time. Keep on reading to discover how to effectively describe and manage tasks for your dev team to lead your project to success.

## Pitfalls of wrongly described tasks

Communication is the foundation of any project. The outcome depends on the team’s efforts on how well they discuss the particular parts of the process, ideas and suggestions. The way in which the initial tasks are described also highly influences the final product. Clear and transparent tasks are easier to understand, leaving no room for misinterpretation and allow the team to start the work sooner. They also limit the time needed for asking questions and solving ambiguities.

However, at times, Product Owners and Business Analysts don’t know how to prepare the tasks for development teams which leads to:

* stress and tension in the development team
* broken deadlines
* exceeded budget
* wasted time

This miscommunication between client and vendor can be caused a variety of issues, including:

* the development team doesn’t understand the business domain
* the business language and technical language differ dramatically
* tasks aren’t sufficiently described and explained

This all can be avoided with a few simple steps. Don’t stop reading to find out all the details.

## How to avoid misunderstandings when assigning tasks

It is crucial for a coder to understand both the problem/domain and the product owner’s expectations to effectively proceed with development. Let’s look at the few important tips to apply to your process.

### Prepare a presentation of the project

![Img](https://a.storyblok.com/f/86602/720x433/0a4c5ec814/prepare-a-presentation-of-the-project.jpg)

A great tip is to begin the cooperation with a presentation of the product and its features. Describe in detail what problems it’s going to solve as well as the business requirements. It’s also a good idea to set any deadlines and present examples of similar solutions. Thanks to this information the development team can start efficiently working on the architecture and estimate how much time they need to finish the tasks.

### Provide a business roadmap

This will help to define the right approach as well as help the developers understand the order of implementation and what are, if any, the dependencies.

### Find a common language

It’s obvious that technical and business languages are different. This sometimes makes it hard for the technical and business parties to understand each other especially if they use highly specific terminology. Make sure the tasks you describe are written in a language accessible to everybody. If there’s no way around such terms you can prepare a mini dictionary of important terms or have both sides agree on what vocabulary to use.

**Bonus tip:** try to always set an assignee, priority and due date for every task as this will help to make the task clearer to everyone.

![Img](https://a.storyblok.com/f/86602/720x383/4b9b4d2c21/how-to-properly-describe-tasks.jpg)

## How to properly describe tasks?

How much attention a developer pays to investigate those expectations and how much time they spend on research is up to each individual, however, as a Product Owner, you can have a huge impact on the quality of requirements specifications and how the latter are managed. The list below may not be complete or it may not fully fit each and every development environment, yet it can act as a strong starting point for building your own set of practices.

### New features and changes

New features are what every product owner loves the most. How to manage the requirements for those to be delivered effectively? The following tips should help:

#### Keep all the updated requirements in one place

There is hardly anything more frustrating than having to look for current requirements in tens of comments under the actual description or having to decide which commenter is actually authorized to change the requirements. The goal here is to keep all the up-to-date requirements and details in the main/primary description of a task. Even though the information in comments may affect initial criteria, just update this primary description accordingly.

#### Consider creating an acceptance criteria list

Descriptive requirements are very helpful when it comes to understanding the context of a problem, yet finally, it is good to precisely specify what is expected. Thus the developer will not have to look for the actual requirements in a long, descriptive text but he will be able to easily get to the essence. One might find that sometimes — when acceptance criteria are well defined — there is little or no need for any additional information. Example:

* *User navigates to “/accounts” and clicks on red download CSV button*
* *Popup appears with two buttons: “This year” and “Last year”*
* *If user clicked on “Last year” download is initiated*
* *CSV downloaded includes following columns…*

#### Provide mockups

A textual requirements description is essential in most cases, but an image is often worth more than a thousand words. Even a simple mockup can limit misunderstandings by a great factor. There are many apps out there that might be helpful here, like Balsamiq, InVision or Mockingbird, but manipulating screenshots of an existing app also works.

<Baner name={know-us} />

#### Provide examples, credentials, etc

If the expectation is to process or generate some file — attach an example of such a file. If the goal is to integrate what is being developed with some service, ensure your devs have access to this service and its documentation. This list could go on and on — the bottom line is — if there is something that our developer might make use of, try to foresee it and provide them with (access to) it.

#### Annotate

The mockup provided can sometimes be confusing for developers. Especially if it contains much more content than the scope of the task described. Drop a couple of arrows, outlines and annotations here and there to emphasize what are the important parts of the mockup from the task requirements perspective.

#### Use charts and diagrams

While it is not always necessary, sometimes it might be beneficial to prepare a flowchart, a block diagram or some other kind of concept visualization that will render it easy for the developer to comprehend the task and its scope.

#### Spoil your developers with details

It is always safer to assume less rather than more domain knowledge in the dev team. Therefore following the KISS principle and augmenting each description or acceptance criteria list with contextual/domain knowledge and details that might become relevant is highly recommended.

#### Describe edge cases and provide constraints

Hardly any developer likes constraints, but if there are some, let them be communicated early. Do we need to support some specific browsers? Does this script need to run below a specific amount of time? Is it crucial for this endpoint to respond in no more than n milliseconds? If there are some such concerns, make sure they are included in your descriptions. Also describing any edge cases might be beneficial. Maybe we have some query limit on a given service? If you have such knowledge it is always beneficial for your devs to know about it upfront.

#### Provide a copy

If there is a long message to be displayed, just provide a copy for it somewhere in the description. Do not place it on mockups as it is always slower and more error-prone to re-type it than to copy-paste it.

### Bugs

![Img](https://a.storyblok.com/f/86602/720x383/1e4eed648e/bugs.jpg)

It might have happened a couple of times that you have received a response to a bug report stating “cannot reproduce”. Hence it is also important how you describe bugfix requests.

1. **Describe steps** to reproduce an issue including as many details as possible.
2. **Provide access** to the affected account and services if possible. It might be hard to reproduce the exact environment on a local machine.
3. **Provide environment information**, i.e., browser version, operating system version etc. Sometimes a list of installed browser plugins and extensions might be helpful as well.
4. **Provide a link** to an exception and/or a stack trace, as investigating those is usually the first step to take in resolving the problem.
5. **Provide access to logs**, as they can be helpful in reproducing the steps that caused the problem in the first place.
6. **Provide access to the affected server** or database dump. If it is possible and when it does not violate security policies, it is usually helpful for the developer to access the original data that might have played a role in the problem.
7. **Make a screencast**. It is not always necessary, but many times a short screencast (or at least a screenshot) says more than a thousand words. While working on MacOS you can use QuickTime Player for the purpose but there are plenty of tools available for other operating systems as well.
8. **Provide contact information** of the person that reported the bug. This will not always be possible, but in some cases, it might be advantageous and most effective if a developer can have a chat with a person that actually experienced the bug, especially if the steps to reproduce a problem are not deterministic.

## How to manage tasks for your dev team?

A well-described task is at least half of the story behind its successful implementation. Some other success factors are hidden in what happens to the task further down the road and especially in how the necessary feedback is provided and processed in the task implementation.

<ReadMore> Read also: [Why Choose Node.js?](https://selleo.com/blog/why-choose-node-js) </ReadMore>

### Prioritize

Ensure your developers know what is the priority order for delivering the tasks in the backlog and make sure they know what tasks to fall back on in case of blockers. Taking priority into account while ordering tasks is usually good enough for the purpose.

### Leave some freedom

The coder sometimes needs to switch from one task to another just to rest — coding the same, large functionality for weeks can be mentally exhausting. The specific approach to resolving a problem should also be decided upon by the developer.

### Keep tasks small

High granularity helps to see and feel the progress, not only by the developer but also by the product owner. Smaller tasks are also easier to comprehend, and estimate and result in smaller chunks of code that cover task requirements. Resultant code in turn is often easier to test, refactor, review and integrate. Allow the developers to create sub-tasks so that they can further organize the steps necessary to accomplish the goal of a given task. Therefore, if you encounter a large task — be it in description, complexity or estimation dimension — do your best to divide it into smaller ones.

### Define who the decision-maker is

Who is responsible for accepting the requirements? Who is the person to kick in when there is some substantial decision to be made? Specifically, let developers know who to contact if they need help or information related to the task being described. Also, make sure that such persons are aware that a developer might contact them. Sometimes there might be a person that acts as a proxy between developers and the other people involved in the project, which makes it even easier to coordinate the support needed.

### Consider employing a dedicated [Product Owner](http://scrummethodology.com/scrum-product-owner/) or a person with a similar role

I.e., a proxy to mediate between the developers and the rest of the company. Such a person might not only be responsible for prioritizing tasks, requirements clarification and other related activities, but they could also present a vision for future product development. Presenting such a vision may affect how developers approach resolving particular problems — they may in fact keep some upcoming requirements in mind even though they have not been instantiated in the backlog yet.

### Communicate deadlines

If there is a deadline to meet, communicate it early and clearly and describe why is it important to deliver the solution by a given date to help developers identify with a goal of accomplishing a set of tasks on time. Also, mark this deadline in the project management software. The deadlines whose only purpose is to mount pressure on your developers will backfire sooner or later, as developers will most probably — in time — stop paying attention to them. However, milestone scopes (quarterly, for instance), which describe what we would like to achieve in a given period — help developers in organizing their work towards achieving a specific goal(s).

### Pick the right software

Last but not least, using the right project management software can greatly help in adhering to the tips mentioned above. Not every project management software is designed for facilitating the software development process, so — if possible, take your time and choose the software tool that is well equipped to do so. There is a variety of solutions available on the market, such as [Pivotal Tracker](https://www.pivotaltracker.com/), [JIRA](https://www.atlassian.com/software/jira) or [YouTrack](https://www.jetbrains.com/youtrack/), just to name a few. The bottom line here is, that you should keep requirements in one, clearly defined place. Scattering tasks between emails, IM conversations and project management software increases the chance of overlooking a particular task significantly.

<Baner name={contact-us} />

## Providing feedback

Depending on the nature of your project and the development practices used it may be necessary to provide feedback to the task delivered by the development team. Sooner or later some developers will also discover that they need more details about the task being implemented. Here are a couple of tips to make the process go smoothly:

1. **Provide responses promptly.** It costs time to switch from one task to another for the developer, so do your best to provide responses promptly and thus avoid the costs of task switching.
2. **When giving feedback to completed tasks, keep it to the point.** Focus on the task description and provide the applicable feedback only. Irrelevant discussions might lead to confusion and the developer not knowing if there is something to be changed or not.
3. **Do not inject new acceptance criteria and/or requirements.** Be it for completed, ongoing or pending tasks, do not extend their requirements. Extending scope may not only affect estimations but it can also violate the “Keep tasks small” recommendation, with all of the associated consequences.

## Summary

Communicating requirements effectively plays a big role in the development process. Doing it wrong may cause delays in requirements delivery or lead to the implementation of features that diverge from the product owner’s expectations, but it can also result in building up frustration and lowering the team morale. The list above might become helpful in mitigating such effects significantly.

To keep the development process running smoothly as well as to sustain productivity and happiness in your developers’ team it is usually not enough to just provide them with good tasks description. Communicating priorities, updates and deadlines, eliminating blockers promptly and restraining are also vital for the purpose. All of these practices handled by a dedicated person as well as the right software will in most circumstances render development efficient and enjoyable.

This post will help you to discover how to effectively describe and manage tasks for your dev team to lead your project to success.

10 Tips On How To Effectively Describe And Manage Tasks For Your Dev Team

Putting together a perfect development team is not an easy task, no matter if you are a team leader or a CTO looking for a new off-shore team to help with your project.

Choosing the right people may be a complicated task and at first, you may think that the more skilled developers - the better. This is not always the case and this article will answer the question **why your teams should not consist only of top-notch engineers**.

#### 1. They get bored with simple stuff

This should not come as a surprise. If you consider the things you work with rather easy and mundane you will **get bored** eventually and your **motivation will drop**. Although sometimes it is good to deal with tasks you can complete without a blink of an eye, they are not the challenges that help you improve and grow.

This is why senior developers should not be the only ones on your team as their motivation and overall job satisfaction will be lower when performing simple tasks. They can tackle the **more complicated** tasks while **mentoring juniors** handling the basics. Here, a mixed-skill level team will ensure that your juniors are getting proper training on a real-life project and the seniors are satisfied with the complexity of their job.

#### 2. They may hate support tasks

Thanks to their experience in programming senior developers love creating stuff from scratch. There is nothing more rewarding than solving a problem by yourself and better than working exactly how you like to work. This is why they will probably oppose performing support tasks or other similar actions. Developers with more experience have a personal coding style and will not enjoy working on somebody’s else code.  Obviously, it does not apply to every single experienced engineer, but this should be kept in the back of the mind next time a support / rescue mission will appear. However, a support task may be a great idea for the less experienced ones to learn from and since it will not require building the entire thing. 

#### 3. They are usually more expensive

Like in the case of every expert, the more experienced the developer - the more expensive the development will be. The infinite amount of hours dedicated to programming and developing skills will obviously influence the base pay rate. The quality code also has an influence on the price. In the end, a higher hourly rate is one of the reasons why we keep on growing and broadening our skillsets. This is why a team created including both junior and senior developers will not be as expensive as the one with only senior devs and more juniors do not necessarily mean worse code quality. 

#### 4. They tend to over-complicate things

Over-complicating can be a burden. Because experienced developers have seen it all they tend to know a lot of solutions to one problem. Therefore when choosing one they may not necessarily go with the simplest option, which will result in a more complex, less readable code. A fresh mind of a junior can be the key to a simpler and shorter code with less complicated features, which may influence the overall performance and time-to-market.

#### 5. There is a risk of conflicting egos

As you may suspect, the more experts - the more opinions. If one considers himself an expert, he will strongly dislike getting guidelines from somebody on the same level. In teams, somebody usually has to become a leader to help manage the work and other people and this is where egos will come in to play. Although in some cases, this kind of quiet ‘competition’ will bring advantages, those conflicts will mostly bring more harm than good. With let’s say, one senior developer and two juniors, the former will become a mentor and take responsibility for the team members while the latter will gain experience and fresh knowledge.





So now a question of **‘Why do I need senior developers altogether then?’** probably popped up in your head. Well, this is why:

#### 1. They are capable of handling most complex tasks

Your juniors will not be able to handle the complexity of your project at some point, this is a given. They will most probably get stuck at some point and will need assistance from the more experienced colleagues. This is why the more complex tasks should be handled by skilled engineers in order to minimalize downtime or get rid of it completely. Seniors can be great mentors and thanks to their experience working with clients will definitely positively influence the relationship with the client.



#### 2. They are needed for planning tasks for other developers etc.

Planning task and overseeing architecture is where the experience of senior developers will come in handy. They will know how to divide task to avoid overwhelming those less skilled while getting results on time. The opinion of an expert is valuable for the entire team and the well-being of the project. Thanks to many hours spent working on commercial projects, a senior developer will be able to estimate the time needed to complete a given task, therefore, providing you with an exact timeline for the entire project.

#### 3. Very valuable as mentors for other developers

As mentioned before, broadening skills and constantly expanding our knowledge is key and learning from others is the best way to do so. Therefore experienced engineers make great mentors for other developers, sharing their priceless real-life knowledge that cannot be found in books and guides. What is more, seniors will not only provide juniors with a ‘coding’ knowledge. They can set an example on how to communicate with clients, how to deal with stress or failures as well as how to maintain a great atmosphere within the team.

### Summary

Those above-mentioned points should convince you that the main characteristic of your team should be cross-functionality. Teams described using this term are the ones consisting of a variety of people on a different skill level introducing collaboration and creating a perfect learning environment.

Diversity is a crucial part of growing, supporting productivity and problem-solving. By mixing developers on different skill levels encourages the atmosphere of learning and mutual support. This will ensure your project is not only of good quality but you are also training next best developers.

Choosing the right people may be a complicated task and at first, you may think that the more skilled developers - the better. This is not always the case and this article will answer the question why your teams should not consist only of top-notch engineers.

Why Mixed-Skill Level Teams Are For You?

Introducing a new developer to an existing project might be a long and unproductive process. Because of that, it is wise to approach this challenge with some kind of plan. In this article, I will focus on the four key ingredients of adding a new team member:

* the new developer
* the team
* the client
* the project

Please note that I am writing this article from the perspective of a team leader that works in a software development house. The dynamics of my position brings a lot of opportunities to be introduced to a new project created by external companies and to introduce new developers to the already maintainable applications.

### New developer

Depending from the experience of the new team member, starting to work on a new project might be both stressful and challenging.

To release tension you can simply** ensure that everything will be alright.** It might sound silly but a few words of encouragement cannot hurt anyone and shows that you actually care.

You should spend some time and **explain in detail the role **a new team member is going to fulfill in your team. It is crucial to make sure that you are on the same page when it comes to your expectations.

If a person is not experienced and the project is gigantic you can be honest and say straight away that you don’t expect much at the beginning. You can agree on some ‘special treatment’ period when the noobie can learn the platform without resolving any problematic features.

When it comes to creating your application more approachable you can **guide through how the application works** and show the most interesting parts of the codebase. But please make sure that new developer understands business goals and contexts behind the application as well as how it works. And whenever possible, **do a pair programming**. In my opinion, pair programming is a marvelous way of helping others find themselves in a new application.

You can also focus on the tasks you assign to the new developer. A small task can be a great way to start, but as soon as possible, you can give him something bigger and more complex. **Finishing a hard task on a new system brings a lot of confidence and builds the feeling of ownership.**

### The Team

Not only the new developer needs attention, your team also demands it. Bringing someone new to the team might raise a lot of questions. Why do we need him/her? Is something wrong? Is client not happy with our performance? Is a substitution planned? Because of that, it is good to have a team meeting **before** we actually add someone new. During that meeting, you can explain the reasoning and answer all the burning questions that your team may have.

Remember that you can always ask your team members for help in introducing the noobie to the project. I highly encourage to **schedule a pair programming session** with each team member. It is a fantastic way to build connections and share the knowledge about the practices you follow on this particular project.

### The Client

There is a great chance that the client (owner of the application) might have an impression that more people equals more tasks done. While it is true after some time, **at the beginning the productivity of your team will not change**. In some cases, it might actually drop a little because of the overhead a new person adds to the project. Someone has to invest time in that person and because of that, the overall productivity might be lower. **Make sure that the client knows and understands that.**

### The Project

I have seen a lot of projects throughout the 11 years of my career. Not all of them were easy to install and setup. To make sure that it is not the case on your project be sure that your** documentation is up to date **(and easy to follow). You should also invest some time and prepare** seeds that actually work **(writing specs for seeds is really helpful to make that happen).

**The most essential thing **that helps to introduce a new developer to the project is a **fast and reliable test suite**. Both unit and integration test should ideally cover each feature in your application. Thanks to that, you have a friendly environment to add/modify functionalities that will prevent your new developer from breaking something on production because of the lack of familiarity with the application.

The other things that are worth mentioning are **code reviews by a more experienced developer and QA** that a feature does what it was supposed to do.

### Summary

There is a lot of things that can be done to speed up adding a new member to the existing project. Some of them are trivial and some of them require a lot of goodwill and some sacrifice. From my perspective, it is worth to invest this effort because it builds foundations to create a happy and cooperative team.

Introducing a new developer to an existing project might be a long and unproductive process. Because of that, it is wise to approach this challenge with some kind of plan.

How To Introduce A New Developer To A Project

This is a follow-up to my previous article: [10+ tips on how to effectively describe tasks for your dev team](https://medium.com/selleo/10-tips-on-how-to-effectively-describe-tasks-for-your-dev-team-c0e13c9a9bab#.xkw8r4uvk). This post is focused more on managing requirements rather than on describing them. A well-described task is at least half of the story behind its successful implementation. Some other success factors are hidden in what happens to the task further down the road and especially in how the necessary feedback is provided and processed in the task implementation.

### Managing tasks

1. **Prioritize**. Ensure your developers know what is the priority order for delivering the tasks in the backlog and make sure they know what tasks to fall back on in case of blockers. Taking priority into account while ordering tasks is usually good enough for the purpose.
2. **Leave some freedom**. The coder sometimes needs to switch from one task to another just to rest — coding the same, large functionality for weeks can be mentally exhausting. The specific approach to resolving a problem should also be decided upon by the developer.
3. **Keep tasks small**. High granularity helps to see and feel the progress, not only by the developer but also by the product owner. Smaller tasks are also easier to comprehend, estimate and result in smaller chunks of code that cover task requirements. Resultant code in turn is often easier to test, refactor, review and integrate. Allow the developers to create sub-tasks so that they can further organize the steps necessary to accomplish the goal of a given task. Therefore, if you encounter a large task — be it in description, complexity or estimation dimension — do your best to divide it into smaller ones.
4. **Define who the decision maker is**. Who is responsible for accepting the requirements? Who is the person to kick in when there is some substantial decision to be made? Specifically, let developers know who to contact, if they need help or information related to the task being described. Also make sure that such persons are aware that a developer might contact them. Sometimes there might be a person that acts as a proxy between developers and the other people involved in the project, which makes it even easier to coordinate the support needed.
5. **Consider employing a dedicated [Product Owner](http://scrummethodology.com/scrum-product-owner/) or a person with a similar role**, i.e., a proxy to mediate between the developers and the rest of the company. Such a person might not only be responsible for prioritizing tasks, requirements clarification and other related activities, but they could also present a vision for future product development. Presenting such a vision may affect how developers approach resolving particular problems — they may in fact keep some upcoming requirements in mind even though they have not been instantiated in the backlog yet.
6. **Communicate deadlines**. If there is a deadline to meet, communicate it early and clearly and describe why is it important to deliver the solution by a given date to help developers identify with a goal of accomplishing a set of tasks on time. Also, mark this deadline in the project management software. The deadlines whose only purpose is to mount pressure on your developers will backfire sooner or later, as developers will most probably — in time — stop paying attention to them. However, milestone scopes (quarterly, for instance) , which describe what we would like to achieve in a given period — help developers in organizing their work towards achieving a specific goal(s).
7. **Pick the right software**. Last but not least, using the right project management software can greatly help in adhering to the tips mentioned above. Not every project management software is designed for facilitating the software development process, so — if possible, take your time and choose the software tool that is well equipped to do so. There is a variety of solutions available on the market, such as [Pivotal Tracker](https://www.pivotaltracker.com/), [JIRA](https://www.atlassian.com/software/jira) or [YouTrack](https://www.jetbrains.com/youtrack/), just to name a few. The bottom line here is, that you should keep requirements in one, clearly defined place. Scattering tasks between emails, IM conversations and project management software increases chance of overlooking particular task significantly.

### Providing feedback

Depending on the nature of your project and the development practices used it may be necessary to provide feedback to the task delivered by the development team. Sooner or later some developers will also discover that they need more details about the task being implemented. Here are a couple of tips to make the process go smoothly:

1. **Provide responses promptly**. It costs time to switch from one task to another for the developer, so do your best to provide responses promptly and thus avoid the costs of task switching.
2. **When giving feedback to completed tasks, keep it to the point**. Focus on the task description and provide the applicable feedback only. Irrelevant discussions might lead to confusion and the developer not knowing if there is something to be changed or not.

3. **Do not inject new acceptance criteria and/or requirements**. Be it for completed, ongoing or pending tasks, do not extend their requirements. Extending scope may not only affect estimations but it can also violate the “Keep tasks small” recommendation, with all of the associated consequences.

### Summary

To keep the development process running smoothly as well as to sustain productivity and happiness in your developers team it is usually not enough to just provide them with good tasks description. Communicating priorities, updates and deadlines, eliminating blockers promptly and restraining are also vital for the purpose. All of these practices handled by a dedicated person as well as the right software will in most circumstances render development efficient and enjoyable.

well-described task is at least half of the story behind its successful implementation. Some other success factors are hidden in what happens to the task further down the road and especially in how the necessary feedback is provided and processed in the task implementation.

Read our articles on Selleo Blog

Business

Technology

10 Tips On How To Effectively Describe And Manage Tasks For Your Dev Team

Why Mixed-Skill Level Teams Are For You?

How To Introduce A New Developer To A Project

10 Tips On How To Effectively Manage Tasks For Your Dev Team

Tell us about your project