How to plan your sprint?
This is part 7 of a long-form series of setting up your Product Stack’s Project Management correctly.
You can read Part 6 about tracking the progress of your Products and setting up cadence for your meetings here.
If you’ve already instituted a process on your Sprint Planning or use the Kanban methodology of Product building, feel free to skip to the next part where I discuss how to construct and maintain a dynamic Product Roadmap.
In part 6, we discussed how to track the progress of your product-building efforts and discussed all the types of boards along with the columns and swimlanes that would be required. Let’s now dive into how you’d decide which Issue to place on your tracking board.
Sprint Planning
The process of Sprint Planning should start with understanding the capacity of delivery of your team for the duration of a sprint cycle. The first key part to understanding this capacity would be the total team size and the total number of days for which each personnel in your team is actively involved in any meaningful work.
Let’s first understand what we mean by the capacity of the team —
Capacity
The capacity of a team is simply the sum total of the total deliverables that a Scrum team can deliver in the cycle of a sprint. It’s important to understand that the capacity of your team and the unit of estimates that you come up with for each task to be picked up for your sprint should be the same.
Estimation
The process of estimation has been described in great detail in this article linked here. You’d need estimates for each of the following Issue Types discussed in part 4 —
- Development Story
- Bug
- Task
- Design User Story
- Copy Writing
- User Research
- Usability Testing
The process of estimation starts off by being wide off the mark with your team members predicting the effort of building to be at least 50% lesser than actual. I’d advise you to start by adding a buffer to everything estimated at about 30–40% to plan your sprint and keep almost 30% bandwidth-free for almost all teammates except good performers.
I’d also advise you to start afresh for new joiners and have estimates for them separately even if the rest of your time is matured into this process.
Briefly covering the units of estimation and capacity planning below -
Story Points
Estimation in terms of story points means assigning a unit of points to each of the Issue Types needing estimation.
The definition of one story point is generally estimated as 1 Ideal Engineering Day which means roughly how much an engineer would spend in a day. If this means 7 hours for your context, then you should equate one story point to 7 hours. However, you could choose to define as 1 story point being equal to 2 days or 16 hours of effort too. It’d be completely up to you.
Generally, you should use the story point estimation technique when your team is mature, the delivery cycles are quite predictable, and your estimation isn’t way off the mark. You shouldn’t start with the estimation process in terms of story points. I’ve rarely seen teams implement this estimation process well when they start.
Time
Estimation in terms of time means assigning hours or days to each of the Issue Types needing estimation.
Estimation in terms of time should ideally be done in days since most of your team members don’t want to estimate any Issue assigned to them at less than a day’s effort except for some cosmetic user interface changes that you may require.
In general, you should start out by assigning each Issue on Jira that needs an estimation of the number of days it’d need to complete. You could assign days in decimals too if something requires less than a day.
You should start out with estimating in terms of the number of days since most of the team members have a good estimate of how much time in hours or days it would usually take for them to deliver.
Sprint Pre-Plan
A Sprint Pre-Plan meeting is a meeting that should be conducted about 4 days prior to the start of a sprint to check up on the current sprint’s deliverables and to decide the priority of the deliverables to be picked up in the next sprint.
The main reason why a Sprint Pre-Plan is important is that without understanding a health check of the current sprint’s deliverables’ current status, you won’t be able to come up with a plan for how much of the next sprint would be available for picking up newer issues.
A Sprint Pre-Plan should generally be conducted between the Product Manager, Design Lead, and or an Engineering Manager or Engineering Lead. Your Design or Engineering counterpart as a Product Manager should be updating you on the current sprint’s health in this meeting and helping you form rough estimates of the next Issues that can be picked.
Please note that you should have higher-level estimates of larger Issues such as Initiatives, Features, or Epics. Only if you have larger level estimates and have prioritized your quarterly or monthly target, you can arrive at the stage of conducting a Sprint Pre-Plan because you’d always be ready with a ready list of action items to be picked.
Between the space of the Sprint Pre-Plan and Sprint Plan, your Engineering Leads and Design Leads should come up with the estimates of each Issue that’s been highlighted as a priority action item potentially to be picked for the sprint.
Sprint Plan
For a Sprint Plan meeting, you should have your Product Managers, Engineering Manager, Engineering Lead, and Design Lead together decide on your priorities and select the Issues to be picked up for delivery during the next Sprint. The Sprint Planning meeting should be held two days prior to the start of your sprint.
The major objective of your sprint planning meeting is to allocate to each of your Designers and Engineers enough Issues such that they would be meaningfully occupied during the sprint.
The definition of being meaningfully occupied could vary from organization to organization. A simple rule of thumb for this measure is if each one of your Engineers and Designers has 7 days’ worth of Issues to be taken up so that even after accounting for some estimation errors, they’d be able to deliver within the timeframe of 10 days if you have a 10 days sprint cycle.
An easy way of knowing how much bandwidth each Designer or Engineer has is to check the Engineering/Design Scrum Board that you’ve set up before the start of each sprint. In order for these values to be in sync, your team would have to update the estimated effort and actual effort on each Issue that you’ve created.
This is the space for accommodating your Technical Debt that you may have accrued over time or some nagging defects that you may been pushing down the road. If you have some bandwidth or capacity of some developers free, you could utilize the same
Tech Huddle
Post your Sprint plan for your Engineering team which should ideally be two days prior, the team should spend time on the list of Issues they have to pick up in the next sprint and come up with the Technical specifications for the same. A Tech Huddle may not always be required especially if you want to build an existing Feature further. However, if you’re building from scratch, Tech Huddle should be the most important meeting that your Engineering team should be conducting.
Tech Huddles should include all of your Engineers working on problems to sketch out the basic architecture and decide upon the API contracts for feature development.
Please note that Product Managers need not be present for Tech Huddles unless there are specific doubts from the Tech team to be clarified.
Sprint Retrospective
Even after doing almost everything with the best intentions, you’d have a lot of instances of process breaks or cases where you or your team won’t have the time to ensure adherence. In such cases, you should air all of this constructive feedback during this retrospective meeting. You could provide feedback about what should be iterated upon in terms of documentation depth and clarity from the Product Managers or the final Design handover to the engineering team.
You can reference this documentation link to learn more about conducting retrospectives.
Summary
You could choose to eliminate any one of the processes and meetings mentioned in this article above except for planning your sprint.
In my experience, the total estimated backlog coupled with the bandwidth visibility of each Engineer or Designer on your team enables you to have the most efficient work allocation and delivery cycles utilizing your resources in the most efficient manner.
Now, that we’ve understood the process of planning our development cycles, we’ll discuss building and maintaining your own dynamic roadmap in the next section.
Do share your feedback with me at kshitj.saxena@gmail.com or connect with me on LinkedIn
