We have all been there, but I’ll pick on me for this blog. During a daily standup, I’ve stated my task is done. Woot woot! Time for a cup of coffee and then onto the next task. Just as the Agile board is being updated the project manager asks: “is the code checked-in?”, “was a code review done?”, “is it deployed to the development environment?”, “did you unit tested?”. Umm…(insert awkward silence). I guess I need a bit more time.
It happens to the most seasoned team member. In my experience, the best way to prevent this is to have a clear definition of what Done is. It varies by team and team member, so define early and incorporate as part of your daily routine.
Define Done
The definition of Done is set of guidelines or checklist to follow. It ensures everyone is on the same page on what is required to get a task completed and how to verify the requirement has been met. Defining Done is not easy, takes time, and is a living document. Without the definition of Done, items are missed, assumptions are made, and an inferior product is delivered. Of all the principles that guide a project team, I feel the definition of Done is in the top two or three priorities.
In this blog, I outline key areas where the definition of Done is most critical. This is a starting point – expand and update.
Note: I will use the term “tasks” for simplicity. The approach is applicable to all project delivery methodologies I can think of.
Definition of Done for Tasks
One of the best methods I have seen is a detailed review of each task by all project team members. In an Agile project, this is often done as part of the planning session. During this session, I ask each team member to review the task subject, requirement, and acceptance criteria. Any confusion, assumptions, or missing details need to be addressed before the task definition is Done.
This is a time-consuming process and I hear lots of grumbling about the time that could be spent doing something else. Each time I run through this process, however, I am reassured this is the right approach as the tasks are matured, assumptions are removed, and the team understands the objectives. The net result is a higher quality product, a team that understands the bigger picture and a happier customer.
Writing task definition and acceptance criteria seems like a relatively straightforward task but writing a comprehensive task (subject, details, and acceptance criteria) takes experience and creativity. A few guiding principles I recommend:
- Is the title short and descriptive? I found this article particularly helpful.
- Are there assumptions in the task? For example, “personal information” may mean multiple things to different team members. Spell out the details and remove the assumption.
- Do multiple audiences (PM, analyst, developer, QA, SME) understand what the task is trying to convey?
- Is the acceptance criteria defined? This post does a great job spelling out why what and how to write the acceptance criteria.
- Is there a priority assigned to the task?
- Ideally, an estimate and high-level design are provided. Depending on the size of the task, an estimate and design might be a separate task.
- …
This list is a starting point but covers critical items.
Done for Development & Test
After many years of writing code and claiming my tasks are done, I can say this with love, respect and confidence – developers are notorious for claiming tasks are done when they are not. Here are statements about tasks I have that were “done”, but with a little poking and prodding, code was…
- Not checked-in.
- Is not part of the build.
- Has not been unit tested.
- Has not been code reviewed.
- …
During the Wild Wild West phase of the project, the focus is on getting sh*t done and compromises are made. That is the reality of project delivery but the problem with some compromises is quality. These compromises are not worth the perceived time savings. Here are some the guidelines I use to define Done for development and test while maintaining quality:
- Code reviews are completed.
- The code is checked-in to source control.
- All files are added to source control.
- The code can compile on someone else’s machine.
- The code is commented.
- The code is maintainable.
- The solution passes positive and negative unit and system testing.
- The solution passes functional tests using the acceptance criteria.
For development tasks, all above items must be accomplished to be considered Done. This is a bare minimum list. For larger projects/products, the list is more comprehensive.
Ready for Demo!
This is the definitive definition of Done – the solution is in an environment where it can be shown off to the customer and other key parties. Assuming the process above was followed, few corrections are needed and ideally, you have a happy customer.
Final Thoughts
Defining Done is not a trivial task and it takes a team to do so. The project’s architect and project manager generally come up with the initial list, but the team helps shape and mature the list. Once the definition is initially agreed upon, print it, and hang it up where everyone can see it daily. It is a living and breathing document, so expect it to change. When you believe your task is Done, refer to the list and verify.
Until next time,
Chris
Miscommunications happen. Anyone that is or has been in a relationship knows this all too well. I find that miscommunication often occurs because feelings are trying to be spared, there is fear of being honest, or the parties are not speaking the same language (figuratively). Unfortunately, the net result is lack of transparency, dishonesty and often being blindsided. Personally, I’d rather have it between the eyes than dance around a topic (I’m not a good dancer – just ask my wife).
1:1s (one-on-ones) are essential. It is time for the employee and manager to have dedicated time to discuss career growth, how things are going, any concerns or questions, and general updates. At times, 1:1s are brief, but use this time to get to know your teammates better and vice versa.
Like it or not, there are going to be times that you are pissed off, upset or sad at work. Emotions are the reality of life. I have worked with managers that believe that as a professional, you should be able to separate your feelings from your job. That is a load of crap. I have been in the position of pissing off a team member and other times where I wanted to fire an employee on the spot because he pissed me off (skipping details).
My Musings 