How to run a Sprint as a Tech Lead efficiently

How to run a Sprint as a Tech Lead efficiently I’ve worked with many teams. Most use Scrum as their development process, but I’ve seen many teams struggle with running a Sprint. The most common problems that I’ve seen in many teams:

• Finishing a sprint with many unfinished tasks.
• Endless tasks, developers pick “task to task” even they have sprint planning.
• Spend a few days from the beginning of the sprint to finish sprint planning and estimate tasks.
• PM/PO often asks for the estimation from tech leads or teams to know when we can release the features.

The velocity is useless for the PM/PO and dev team. It’s not stable; it fluctuates every sprint. That’s why my boss always asks “why velocity is so low?”, “why velocity is not stable?”, …

Many textbooks, articles, and videos teach you how to run a sprint, but it’s not easy to apply these techniques to your team. That’s why I want to share my experience with you. I hope this can help you to run a sprint effectively.

1. Sprint Planning

To have good sprint planning, really focus on “planning”, you need:

• Trusted velocity: Velocity is a tool to help you estimate how many points the team can deliver in 1 sprint. If you implement Scrum correctly, the velocity is accurate and stable, and you can see how valuable it is.
• “Refined” tasks: All tasks must have full description and correct priority. Full description means you need to have a clear definition of done, how to implement, how to test, how to deploy, … Priority between tasks must be correct. You need to know which task is more important than others.

When doing sprint planning, the team just needs to pick tasks from the top to the bottom until they reach the velocity. If the product has good OKRs, product roadmap, Sprint planning is a great place to discuss the priority of tasks. Ask yourself “Does this task help us to achieve our OKRs?”, “Does this task help us to finish the feature on the roadmap?”.

Usually you need to reduce number of “distraction” tasks. These tasks are different between teams, but you can spot them via a few sprints. You should start observing which tasks are slowing down the team. In my experience, these tasks are often related to bugs and customer support. Once you spot them, you can discuss them with the PM/PO to find a better way to handle them. For most cases, you should limit them in the sprint: 1-2 bugs, customer support tasks per sprint.

2. Daily Standup

Make sure the daily standup is a place to discuss the sprint’s progress, not technical problems. Give quick updates about your tasks. One person should share screen, show tasks on Jira, Trello, … when they are talking. If tasks are in incorrect status, update their status during the meeting (in Jira or Trello). PO and Tech Lead should focus on the “blockers” of the team. If there are any blockers, they should be resolved as soon as possible. Usually, team members are not confident enough to say they have blockers. So before the meeting, you should do some small exercises:

• Check sprint reports, find the sprint report or burndown chart: If the team is behind the plan, there are potentially blockers. Check the control chart(cycle time chart): If the cycle time is increasing, there are potential blockers. Find tasks with high cycle times and ask the task owner about the blockers. Usually it will take 5-10 minutes for daily standup. If there are any technical problems, you should discuss them after the meeting.

3. Sprint Grooming

It’s stressful, boring, and a waste of time for most teams to run the sprint grooming meeting. The backlog is huge, tasks are not well defined and estimated, the team is not ready to discuss about the tasks. They just go through the tasks, ask for the estimation, and then move on to the next task. There are endless tasks, making the session boring.

If you feel this way, you properly do sprint grooming in the wrong way. The sprint grooming is a very important meeting that makes the sprint successful. To make the meeting more rewarding, the PM/PO and Tech Lead should prepare the tasks before the meeting.

Sprint grooming is for Sprint planning. You just need to ensure you have enough tasks for the next sprint. If your velocity tells you that the team can finish 30 points in 1 sprint, you just need to refine 30 points in grooming sessions. You can stop the meeting when you reach 30 points or by 1 hour of meeting.

The PM/PO and tech lead should come up with a list of tasks ready to be discussed, ideally before 1 or 2 days of grooming sessions. The tasks must have a full description and correct priority. If you have a messy backlog, poorly defined tasks, and no priorities, it’s okay. You only need a limited number of tasks for the next sprint. There are 2 ways to get “refined” tasks:

• Async refined tasks
• Team refined tasks

If your tasks list for the next sprint is not ready, you can do async refined tasks. During the sprint grooming, the work is pretty simple: pick tasks from top to bottom and assign them to the team members.

• If the task is poorly defined, you can assign a PM/PO or tech lead to fill in the missing information.
• Otherwise, you can assign to the team members to refine the task. Team members will research the tasks, fill in how to implement, how to test, how to deploy. And then they will estimate the tasks. All steps can be done asynchronously.

The meeting should be short, usually take about 15-30 minutes to assign all tasks to team members. Ask team members to refine the tasks, treat the work like “code review” work. This should be more enjoyable.

You should do sprint grooming weekly. If all tasks for the next sprint are well defined, team member already filled all missing information, and estimated the tasks. This is a great opportunity to estimate the tasks by team. You can use planning poker, or just ask team members to estimate the tasks. The estimation should be done by a team, not by the individual. The process can be straightforward. For each task, the assigned team member who did research, filled in the description, implementation and estimation will present the task to the team. The team will ask questions, raise concerns, alternatives, edge cases, testing efforts… about the task, and then vote for the estimation.

If you do Sprint Grooming well, you will do Sprint planning very easily, and the velocity will be stable and accurate. When you start the sprint, every member knows every task from concept to implementation, and they will be more confident about finishing the tasks. You are always ahead of one sprint. PM/PO knows when the feature will be released, so they will LESS ask for the estimation or when we can release the feature.

4. Sprint Retrospective

I saw many teams raise many problems in the Sprint retrospective and usually they are not resolved in the next sprint. Because they ran the sprint wrongly so all metrics are not accurate. Then we can not measure the improvement.

As I mentioned above, you can spot some tasks slowing down the team. The Sprint Retrospective is a great place spot them. Look at the velocity, if you have lower velocity, it can be blockers from stakeholders, bugs, customer support tasks, …

Try to observe this and you can see the patterns, e.g if sprint has too many bugs or customer support tasks, the velocity is lower.

As a leader, you will have a lot of data to analyze, you can see the patterns if you run the sprint correctly.

This is my general guide to running a sprint. There are many other issues that you will face when running a sprint, like different estimations between team members, teams…

If you have any questions, feel free to ask me. I’m happy to help you.