To-do lists, checkboxes and the definition of done
As Software Engineers, weāre always looking for the next project or feature to work on.
And even though I must admit that moving forward is the way to go, I have to say that not everyone knows exactly when the thing they are working on is actually done. The main problem I see here is if a tech team doesnāt define how things are finished, a projectās deadline is most likely going to be affected by the domino effect of incomplete task after incomplete task.
With past experiences working with Agile teams, we used the Definition of Done to ensure and agree that, given certain criteria, a User Story is considered to be ādoneā. By failing to meet that criteria, weād know that a User Story is yet to be finished and we need to act accordingly: reprioritze, reestimate and revisit the Definition of Done once again to make sure everyone understand what has to be done in order to finish that story on the next sprint or sprints.
But what if your team does not run sprints, retrospectives, work with user stories and is far behind from being a āagileā team?
Thatās certainly not a problem and being āagileā doesnāt mean we get things right all the time. But that doesnāt also mean we canāt do anything to mitigate this problem.
As a rule of thumb, I make use of simple āto-do listsā or āchecklistsā on a daily basis so I know what I have to do regarding X member of my team, things to watch out for when attending meetings or what I need to do in order to finish any task Iām working on.
We donāt need any fancy tools to get started with this process. Markdown, todoist, Notion, Evernote... any tracking method you decide to go for is better than no tracking method.
You can also add a section "Definition of Done" to your issue tracker so every new issue comes along with it. That's a neat strategy to enforce the team to be aware of the pre-requisites before closing the issue, merging a pull request or even shipping to production.
Benefits
- Easier to define the scope and scale of a project or feature.
- With a checklist in place, our brain doesnāt have to hold on to so much information.
- Progress is clear and visible: we can monitor the status of a project without mentally having to keep track of all moving pieces.
- Donāt repeat yourself (DRY): should any project or task be similar in the future, we already possess a recipe of the things to look for and pay attention to.
I hope that's helpful and interesting to you. šš¼
Did you know you can help me with this page?
If you see something wrong, think this page needs clarification, you found a typo or any other suggestion you might have feel free to open a PR and I will take care of the rest.
My entire site is available to edit on GitHub and all contributions are very welcome š¤š¼.
Hemerson Carlin, also known as mersocarlin, is passionate and resourceful full-stack Software Engineer with 10+ years of experience focused on agile development, architecture and team building.
This is the space to share the things he likes, a couple of ideas and some of his work.