The lifespan of a ticket has been analyzed in a previous article (Hello world, I am a ticket), so now is the time to see it from the developer’s perspective. Some of the tickets are really simple and easy to do, but there are some of them that are tricky and may cause problems. So what are the things you should have in mind as a developer when dealing with a ‘naughty’ ticket and how to deal with them? The first contact a developer has with a ticket is in the weekly discussion (Working with your teammates to deliver a product) where the ticket’s issue is described. The developers’ team talks about the best possible implementation and then they ‘poker’ for the ticket. Poker is a procedure where developers calculate how many points the ticket will cost. The points usually match working hours or ticket complexity. At this point, there are two things that could go wrong. The first is that the implementation is not right. In this case, when the developer realizes that the ticket can’t be done with this implementation, he asks the team to re-discuss it on the fly, or he removes the points of the ticket and waits for the next weekly discussion. The second is that the points of the ticket are not enough for the developer to do the job. In this case, the developer should commit and push (assuming the team uses git) his work, and then create a new ticket that will be a follow up of the existing one and will contain the code written by now. The new ticket will be discussed in the weekly discussion. Increasing the points of the ticket is wrong practice because in this way the total points of the sprint are increased. Also if the developer spends too much time with one ticket, he may end up not having enough time at the end of the week to complete the other tickets of the sprint. While working with a ticket the developer may find a new bug that isn’t related to the initial issue of the ticket. In this case, he should notify the testers about it, in order to make a new ticket. If the bug is something really easy to fix or is very critical and the developer decides to fix it in this ticket, he should include some notes in the ticket’s description to tell the tester to test it. A common mistake is that the developer starts fixing things that are out of the tickets scope without considering the time needed for the fix and without notifying anyone about it. In this way, he may end up spending too much time on the ticket, and the changes he made without telling the testers may end up in production without being tested. Also, there may be another ticket for the issue he found, for which he is not aware of, so his extra work may end up duplicated and with conflicts. Another common mistake is that the developer didn’t test the ticket enough before pushing it. As a result, the ticket bounces many times, either due to automation test or by a tester. This means that extra time is needed for developing and testing again and again and may end up consuming the ticket’s points before it is completely done. So the developer should be cautious with every ticket if he doesn’t want it to end up a pain in the rear.