Before starting a sprint, it’s important to decide how much work can be fit into the upcoming sprint. As a team, We’ve chosen to use hours as the measurement for work. We start by prioritizing work in the backlog, ensuring the big tasks important to the next release are near the top of the backlog.
All stories, tasks, and bugs you’re planning to address in the coming sprint should have hour estimates associated with them. I recommend estimating in the pessimistic but realistic range. We always estimate as a team to ensure a diverse set of skills and experiences are taken into account. It’s helpful to provide hour estimates for a bit more than a sprints worth of stories to allow some movement of smaller tasks in and out of a sprint.
Once you have estimates for tasks, work backwards from the release date. We release every two weeks, going to production on Wednesday. This means we need to release to staging on Monday for regression testing. A Monday push to staging means code freeze needs to be the Friday before. As a new sprint technically starts on a Wednesday with the release to production, we have eight working days in our sprints (the other two are technically QA and bug fixes, but usually we start work on the next sprint). We plan for 30-32 working hours a week. Meetings are not counted as part of working hours. Look at any planned unavailability on your team. If someone has scheduled time off, sprint hours should be reduced accordingly.
Calculate the available hours (3 full time devs x 8 days x 6 working hours = 144 hours). Only schedule 144 hours of effort in the upcoming sprint.
I find it helpful to have team members track their time on tasks. Estimating is hard, and we can use the actual vs estimated time to talk about what we missed in our initial estimates. The goal is always to get better as team.
Repeat, communicate, and improve. Good process takes time. Actively working to evolve is the first step.