How 80% of my tickets get closed and never re-opened again. The Definition of Done
In this post I'll explain how to close tickets so they won't be given back to you, saving everyone time, increasing your productivity and making you look like the rock star you are.
First you must understand that to become more productive than the good or average folk you must save time for yourself and for the people around you.
How much time can be wasted by a minor and simple bug that you forgot to fix?
Imagine a minor, overlooked bug that was found a couple of months after you fixed an issue. The customer has to call for help, the help desk person has to answer the phone and document the incident, the incident is reported to the Project Manager or Tester, and they have to replicate and create the tickets for the issue and assign it to you. You'll then have to read the code, the requirements and re-learn that piece of code. With a minor bug you'll probably fix it in ten minutes. Now the ticket must be tested, an updated build be created and prepared for deployment, notifying the customer and sending the release notes. So even though you did the fix in ten minutes, because the fix wasn't done as part of the initial ticket, hours were now wasted on a simple task. There are no simple or minor tasks, every little detail is important.
Another story, once I worked on a financial place and the application was used by about 60 people. That means that if the application doesn't work for ten minutes, ten total hours of work are wasted, plus the results of the outcome of that time, that could of have been a 4 to 5 digit amount (per ten minutes).
With a strong 'Definition of Done,' a 10X Developer can be a force that makes the whole project and team faster and more productive.
Done - A ticket is done when it is closed right, but how fast can you get it closed? How long will it stay closed?
You want to close the ticket fast while ensuring that at least 80% or more will not come back to you. For this we'll define done as:
- The task must be completed as the original request and story expects it.
- The task must be tested for every scenario that you feel that could happen at least once a year. Remember Murphy's Law, with enough time something will happen.
- If the requirements are not clear (it contains words like "Almost" or "Maybe"), don't assume the outcomes, be 100% sure about what are the outcomes expected. Talk to whoever you need to in order to get the information necessary to be certain. Remember you want the job to be closed forever.
- What if the Project Manager and customers are not fully sure about the requirements? Yes this happens especially if we are keeping backward compatibility with other systems. It's OK, you might get the ticket back sooner or later, just make sure everyone (Developers, PM and Support) understands that this ticket might not be fully understood and to make sure it is easy for a future developer to work with or understand this ticket.
- Test every scenario, you'll hate to test some tickets because they have multiple scenarios. But what I hate the most is when I get a ticket back because I didn't test one of the scenarios. So if you feel bored because of testing remember what would happen if you don't test a scenario and the ticket is given back to you. Or worse, what if it gets to production, you find out, and while you are fixing it the customers also find it? Now people start asking you questions about something you already know, burning time and increasing stress. In a summary: Test, test, test.
- What if it's just too much to test? I see this normally in financial systems every little action causes all the balances to change in a different way. I love to test this kind of scenario using integration test, just setup the test to create data for every possible scenario and write all the tests needed. The big advantage is that once written you can quickly test these scenarios, and mostly this kind of code doesn't ever change, the numbers might change but not the process.
- You must have high coding standards and follow them. A ticket might get re-opened just because it doesn't follow standards and is risky. Treat warnings as errors and fix them.
- Make sure test procedures are updated and clear in the tickets and/or explain them to the tester. You don't want the testers to come to you every few minutes asking you how to test a ticket.
If you follow the steps above you'll notice that you'll deliver better code and overtime you'll be a better 10X developer. Remember managers put employees in two simple categories:
- People that make their Job easier
- People that make their Job harder
Be your own category and make everything easier and better.
The 10X developer category.
Thanks for reading and please share and leave a comment below.
What did you like? What would you change?
Another story, once I worked on a financial place and the application was used by about 60 people. That means that if the application doesn't work for ten minutes, ten total hours of work are wasted, plus the results of the outcome of that time, that could of have been a 4 to 5 digit amount (per ten minutes).
With a strong 'Definition of Done,' a 10X Developer can be a force that makes the whole project and team faster and more productive.
Done - A ticket is done when it is closed right, but how fast can you get it closed? How long will it stay closed?
You want to close the ticket fast while ensuring that at least 80% or more will not come back to you. For this we'll define done as:
- The task must be completed as the original request and story expects it.
- The task must be tested for every scenario that you feel that could happen at least once a year. Remember Murphy's Law, with enough time something will happen.
- If the requirements are not clear (it contains words like "Almost" or "Maybe"), don't assume the outcomes, be 100% sure about what are the outcomes expected. Talk to whoever you need to in order to get the information necessary to be certain. Remember you want the job to be closed forever.
- What if the Project Manager and customers are not fully sure about the requirements? Yes this happens especially if we are keeping backward compatibility with other systems. It's OK, you might get the ticket back sooner or later, just make sure everyone (Developers, PM and Support) understands that this ticket might not be fully understood and to make sure it is easy for a future developer to work with or understand this ticket.
- Test every scenario, you'll hate to test some tickets because they have multiple scenarios. But what I hate the most is when I get a ticket back because I didn't test one of the scenarios. So if you feel bored because of testing remember what would happen if you don't test a scenario and the ticket is given back to you. Or worse, what if it gets to production, you find out, and while you are fixing it the customers also find it? Now people start asking you questions about something you already know, burning time and increasing stress. In a summary: Test, test, test.
- What if it's just too much to test? I see this normally in financial systems every little action causes all the balances to change in a different way. I love to test this kind of scenario using integration test, just setup the test to create data for every possible scenario and write all the tests needed. The big advantage is that once written you can quickly test these scenarios, and mostly this kind of code doesn't ever change, the numbers might change but not the process.
- You must have high coding standards and follow them. A ticket might get re-opened just because it doesn't follow standards and is risky. Treat warnings as errors and fix them.
- Make sure test procedures are updated and clear in the tickets and/or explain them to the tester. You don't want the testers to come to you every few minutes asking you how to test a ticket.
If you follow the steps above you'll notice that you'll deliver better code and overtime you'll be a better 10X developer. Remember managers put employees in two simple categories:
- People that make their Job easier
- People that make their Job harder
Be your own category and make everything easier and better.
The 10X developer category.
Comments
Post a Comment