Effective task reporting - 6 rules that will speed up your development process

Task completion reporting may not be the most interesting part of the software development process, but when it’s done right it can be both effective and effortless, significantly speeding up internal testing and customer acceptance. Good reporting ensures that everyone is on the same page, minimizes guesswork, and allows you to identify potential misunderstandings. It also helps to make sure that work reported as finished is actually done. In the end, it contributes to speeding up the development process and shortening time to market for new features. To make it happen, I suggest introducing 6 simple rules of good task completion reporting.

1. Done but not reported is not done

Nobody likes writing status reports, and software developers are certainly no different here. It is simply more interesting to write the next portion of shiny new code rather than a mundane report. When the task is done, it is done, problem solved, bug fixed, feature implemented. Why bother reporting it to someone? Not all developers have this attitude but if some of them do, it may cost your project many hours of unnecessary and idle waiting. It doesn’t matter if a task was finished this morning, yesterday or a week ago if nobody knows about its completion. Done but reported late or never increases the amount of work in progress (WIP) and kills a dev team's capacity.

The later a completed task is reported, the later it will be tested; the later it is tested, the later it will be refined, re-tested, deployed, etc. And all the delays in reporting at each phase of the development process adds up and tightens project deadlines. This means the risk increases of either longer time to market for the final product or it is of poorer quality. End users and business owners won't be satisfied. And excuses like "yes, it is done, just forgot to tell you" can make things even worse. To avoid all this, take this one rule to heart - there is no such thing as done but not reported, it is just not done yet.

2. Always add comments

And I recommend that you be very strict about this. Even adding the shortest comment, like "Done", can be highly beneficial because it ensures that task status change was intentional, and it wasn't just a misclick in a project management tool. But of course, I strongly encourage you not to settle for single worded reports. Short descriptions of a task's outcome can be useful even for small and straightforward issues. Reporting such tasks is usually just a matter of rewriting its summary in your own words. And this is important because it shows whether tasks were understood correctly and helps to identify misunderstandings and potential errors. It also forces the actionee to once again confront his work with the expected result described in the task summary.

Results count, but in many cases, describing how they were achieved is equally important. For example, if a task's goal was to disable some app module for a particular user group, it matters if the module was just hidden or were the permissions adjusted so this group actually cannot access it. It is like asking a waiter to deal with a fly in your soup; even though the result may be indistinguishable, it makes a difference if he brings us a new bowl or just takes the fly out. Leaving a short comment that indicates the selected approach can save someone from guessing, prevents doubts, and helps to verify the result.

3. Keep it short enough

Leaving a comment is important, but excessively long reports can be even worse than no comments at all. There are two important problems with them: the time that someone has to spend on writing them, and the time that one (or more than one) person has to spend on reading them. Leaving no comments for completed issues saves the time of the actionee but may cost more time of the task's recipient. To find out how and what exactly was done, we have to look for some answers by ourselves. However, providing too much information can be equally time-consuming for the recipient and also requires the actionee to spend a lot of time on unnecessary elaboration.

Keeping it short enough is important, but of course, what exactly does enough mean? Unfortunately, there is no golden rule here because it all depends on the size of the task and even more on its substance. But from my experience, writing a good task completion report usually takes somewhere between 1-2% of the time spent on task execution. So, for example, a simple task actioned in 1 hour can be reported in about a minute - in this case, two sentences of summary should be enough. But for tasks that took one or several days to complete, it may take anywhere from 5 minutes up to an hour to provide a good report. It cannot be treated as a determinant, because some issues, despite short execution times, may require more explanation. And what if it isn’t possible to describe the outcome in a clear enough way using just a few words or sentences? What if some longer manual is required to allow anyone to test or use it? The next rule may help here.

4. A screenshot is worth a thousand words

Most web and mobile development work has some visible results in the user interface. Even if the implemented code doesn’t relate to front-end work directly, it usually produces some outcome that finally gets to the screen. That’s why screenshots may be the simplest way to document completed work. There are many tools that allow us to take screenshots and comment on them by adding text, arrows or highlights. Such tools usually also provide a quick upload to the cloud and sharing via link. In Accesto, we use Monosnap for this purpose, which we find to be one of the best due to its great user experience. But there are many of them, just to mention a couple, try Lightshot and Skitch.

This method is way faster to show how something was implemented than to describe it in words. And placing a few arrows with comments on a screenshot is perhaps the easiest way to instruct someone how to use delivered features. Using such a visual form not only speeds up reporting but also can save the valuable time of the report recipient. For some tasks, it is sufficient to verify and accept their outcome just by looking at a screenshot, without having to log in directly to the application.

If a screenshot is worth a thousand words, then a screencast can reach a value of perhaps a million. One of the advantages of Monosnap is that it allows you to also grab a short video and share it just like a screenshot. Such screencasts, usually with audio commentary, are a great way to do a short demo of new features for end users or business owners.

5. Show them how to test it

One of the main goals of reporting is getting acceptance of the work done. That is why a good report should provide all necessary information required for effective assessment of the implemented work. Providing clear information regarding where, what, and how a task can be tested makes the testing process smooth and contributes to quick acceptance. It may also prevent situations where work is done but, for example, not deployed to any server where it can actually be seen by testers or businesses.

Such info does not have to be lengthy. Usually, it is enough to paste a single link or list of links to implemented features. Sometimes, a few additional words of comment may be useful to explain how to access or trigger the feature, especially if it requires some additional action or login credentials. Let's have a look at a simple feature such as a password reminder; testing it may, for example, require execution of some additional command responsible for sending emails from a test server. On such a server, there may also be some mail catching service that prevents emails actually being sent to anyone and gathers them in one test inbox instead. Providing info about this command and a link to the test inbox may save everyone’s time.

Showing how to test implemented features has one further benefit - It ensures that both the reporter and recipient of the report check the feature in the same environment. It is a quite common situation when something works like a charm in the local environment (usually the developer’s computer) but not on the test server or production. Providing the exact place where a feature can be verified helps to catch many potential errors before they are actually tested.

6. Let them forward your comments

The last rule may not be that obvious, but it can be a real time saver. Depending on your project management methodology, there may be different levels of hierarchy and contact points in the development process. And there is no bigger waste of time than rewriting reports from one format to another, just to pass them further in the process or higher in the hierarchy.

Good reports are only written once and should be easily forwardable. They require some discipline from developers and having a common language that is understood by both business and tech people but having this in place may save a lot of time. As a rule of thumb, I suggest to always write a report in a way as if the report was written for the business owners or end users, and not for a project manager or the testers.

Effective and effortless reporting

Reporting completed tasks tends to be a neglected part of software development processes but, if done correctly, can be very beneficial. It helps with internal testing and customer acceptance, minimizing guessing and misunderstandings. It can be a time saver for the development team and can shorten the time to market for new features. And when done the right way, it doesn't have to be difficult or time-consuming.

Two simple sentences with a screenshot and a link to the implemented feature are usually enough to ensure a recipient that tasks have been understood correctly and the proper solutions have been implemented. It may also help to catch many errors before reporting task completion and ensures that it is actually done and ready for testing. And in the end, it can save significant amounts of time. One minute invested by the task actionee into proper reporting may save even an hour of another team member’s time, and what may be more important is that it will show respect for the time of the business owners.