Tracking Task Estimation

Problem

"Whether it be overestimating or underestimating, it's no easy feat to track ticket estimation and completion within sprints. An imbalance in visibility and accountability can lead to unclear priorities and status updates."

Actions taken

• One of the things we do every sprint is to set the total number of points per person at 10. If a task is more than five points, we break it down into separate tickets.
• We also make sure that we also estimate for QA and for the ticket to be closed in the sprint. That means, that when a developer completes it, it gets code reviewed. It then gets marched into the branch, or however you do your branching or marching, and then it gets reviewed by the QA before being closed. The entire thing gets taken into an estimation when we create and put something into the sprint. If that is not complete then we revisit it to see where we went wrong.
• Keep things balanced. To me, it's more about prioritization of what is important. There are only so many things that you can do in a sprint, so if we end up adding something, then we absolutely have to take something out. At the end of it all when we do a retrospective, we have a KPI and OKR document where one of the KPIs is how many tickets we took on and the other states how many points we finished.
• With a week advance notice, we generally send out a filter to the teams and let them know when we are doing a sprint planning. With this, we give them a tentative list of tickets for them to look over and come back with any questions or concerns. Then, the day before the sprint planning we actually play a 20-minute poker plan to estimate the tickets. Finally, on the day of the sprint planning, we set aside about 15 minutes where the tickets are assigned, followed up by a quick retrospective, and then we are done.

"One of the things we do every sprint is to set the total number of points per person at 10. If a task is more than five points, we break it down into separate tickets."

Lessons learned

• We have two-week sprints and I have seen that most engineers are not able to complete more than their allocated points for the sprint. The good thing about saturating a sprint with so many points per person is that the backlog for us is always good. You can always pull from the backlog, which is communicated ahead of the sprint.
• I have noticed that if you do not have the Jira board open, most engineers tend to give an update that really doesn't make sense because you can only take on so much. However, if the board is open, you actually know what tickets they are working on.
• Even though it might seem a bit dictatorial at the beginning, being strict about ticket estimation and completion is important for enforcement. What I have seen is that people are averse to change and start to think they are incapable of completing things because of its difficulty. However, as a few sprints pass, engineers and QA people start to appreciate it because they are included in the sprint process. It's not so much that you need to test these tickets, but making sure that it's complete if you say it's done. Even the QA people have Jira tickets because we use it as our tracking system. Every morning during standup we actually open up the Jira board, go through it, and say all the tickets that have been taken along with their statuses.
• I have also noticed that engineers tend to help out other engineers without including those things in the update. So when you actually have the Jira board open and you go through every ticket, they have to tell you why there is no progress. It helps to clarify where the priorities are and what is getting worked on. Sometimes, an emergency or production issue comes up and if for some reason it's not on the sprint board, that is a good way to address that someone has begun working on it and that it should be added while something else is taken off.
• When you track this quarterly in front of all the engineers, they can see if they are not doing a good job of closing their tickets. Making it open and letting them know that it is being tracked and that you are looking back on it for incomplete tasks will push them to take on less and focus more on what they need to do. Sometimes certain engineers can do a whole lot more while others cannot, so it also helps to determine which engineers can take on what.