Marking a task as complete

Marking a task as complete

This article explains how you mark a task as complete. Most people finish a particular task and simply mark the task a complete. That is not sufficient. You need to provide some sort of artifact (comment, screenshot or screen recorded video) that explains what you did to the task and how you did it.

Why should you provide an artifact before closing the task?

The idea is to make the amount of effort required for someone else to review your work as minimal as possible. The review should not have to open his laptop, sign in to the user account, navigate to that page and then figure out if you implemented the task correctly. Sometimes the reviewer will not have the right test data because of which it will take him additional time to verify it.

But it is more work for me. Why cant the reviewer just open the laptop and check it out?

You might argue – Creating video and screenshots is a lot of work for me. I just finished the task, now you want me to do this also?

This is being penny-wise, pound foolish. You just wrote the code, you have the screen open in front of you. The marginal cost of creating that artifact is the same ‘x’ minutes of your time. In all likelyhood, the reviewer will be in another context. He is going to take ’10x’ minutes to verify your work. In the first instance, the team spends ’10x’ minutes verifying your work. In the second instance the team spend ‘x’ minutes(creating artifact) + ‘x’ minutes reviewing artifact. There is an 8x minutes savings for the team in the second option.

Don’t you want to work in a team that thinks of saving your time or do you want to work in a team where individuals want to solely think of saving their own time?

The testing team benefits big time

The testing team can go through completed tasks and figure out what was intended to be deployed and how it was implemented. They don’t have to sit next to you and ask you how it works. They can figure it out from the completed tasks. Good for you, you just saved more time.

The product team will stop bothering you over time

Managing software complexity will hit your team one day or another. Sooner or later it will become difficult for the product manager to remember all the functions that were implemented and how it was implemented. He is going to interrupt your work every now and then and ask you how it was implemented. With no artifact at the time of closing the ticket, the team loses, so do you.

Implementation details

Let’s say a task was created as shown above. The creator of the task can clearly articulate what the issue is. Depending on the scenario, your closing comment can be text that describes what you implemented. Screenshots and screencasts are preferred.

In this case, a screenshot will more than suffice. If you annotate the screenshot, even better. The user if you trust you to write good code, can sit here and see how you implemented the functionality from a product/implementation perspective.

When will you need a screencast?

If you are creating a flow or a large feature set, a screen recording of the feature where you quickly click through the flow showing the happy flows and failure flows will be immensely useful for the reviewer.

Alex J V
Posted on:
Post author

Leave a comment

Your email address will not be published. Required fields are marked *