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
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.
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.
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
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.
- Describe steps to reproduce an issue including as many details as possible.
- Provide access to the affected account and services if possible. It might be hard to reproduce the exact environment on a local machine.
- 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.
- 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.
- Provide access to logs, as they can be helpful in reproducing the steps that caused the problem in the first place.
- 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.
- 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.
- 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.
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 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 the chance of overlooking a 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
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.
