To-do lists, checkboxes and the definition of done

To-do lists, checkboxes and the definition of done
Photo by
By Hemerson Carlin
2 min read

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 of incomplete task after incomplete task.

With past experiences working with Agile teams, we used the 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, , , ... 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 (): 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 are very welcome 🤙🏼.

mersocarlin

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.

Previous Blog Posts