This is a follow-up to my previous article: 10+ tips on how to effectively describe tasks for your dev team. 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
- 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, 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 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, JIRA or 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:
- 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.
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.
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.
