How can you align sprint planning with your team's capacity and skills?

While it's important to respect your team's capacity, it's equally vital not to underestimate their ability to stretch and grow. Sometimes, putting a little pressure on the team can lead to surprising results. Of course, this should be done thoughtfully and responsibly, ensuring that it doesn't lead to burnout. The goal should be to challenge, inspire and motivate the team, rather than simply piling on more work.

To align sprint planning with team capacity and skills, I begin by understanding each team member's strengths and weaknesses. Then, I prioritize tasks with the help of the technical lead and developers based on their individual skill sets and distribute work evenly. Regularly reviewing team capacity and adjusting as needed ensures a balanced workload. Additionally, I involve the team in sprint planning to gather input and set realistic goals. This approach optimizes productivity, minimizes bottlenecks, and promotes a harmonious work environment.

Team capacity is your sprint compass. Like a ship's captain, assess the winds of your team's skills and energy. Chart a course that leverages their strengths, ensuring smooth sailing towards sprint planning success.

Ideally you have an engineering manager who can help you understand the team's capacity to deliver work. In the best case scenario, you have a program manager as well to understand how that capacity is being utilised. In many cases, though, you're likely to have just one of those two. Your focus on assessing the team's capacity should extend beyond the availability they have and into what skillsets and strengths exist within the team. As development challenges surface, you'll be better equipped to pick the right team member to take on certain work or help solve a problem--as well as know when not to disrupt higher priority work that a team member with critical skillsets needs to do instead.

A simple but often overlooked step is checking if there're any planned vacations, public holidays or other team events (workshops, town halls, conferences).

Prioritisation is the most fundamental skill in product management. You have to be relentless in your prioritisation efforts and you need to be able to substantiate and defend those decisions. The backlog also needs to be prioritised. Doing so will ensure that your team will always know what's next and can quickly pick up projects as work on previous tasks wraps up. A prioritised backlog means engineering doesn't need to wait to be told what to do next.

Putting the most important stuff at the top of your to-do list is super important for making your project work well. It's like making sure you eat your veggies before dessert. You can do this by looking at how much your team can handle and using fancy methods like MoSCoW, RICE, or Kano to figure out what's most urgent and valuable. This way, you'll make your customers and team happy by doing what matters most first. Plus, checking what worked and what didn't in the past helps you get even better at it, like learning from your mistakes and getting closer to success.

Using MoSCoW, RICE, or Kano isn't just about ranking backlog items; it's about defining your product's value model. MoSCoW helps you distinguish between 'critical' and 'desirable,' but these categories can shift due to new data or resource changes. The numbers RICE offers can be misleading. A feature with high 'Impact' but low 'Reach' might still be crucial if it targets key users. 'Confidence' should be substantiated by qualitative insights. Kano categories aren't static; an 'Exciter' can evolve into a 'Basic Need.' Your backlog should be a living document, updated with real-world data from sprints, user interviews, and tests.

Aligning sprint planning with your team's capacity and skills is essential for delivering successful and sustainable results. - Understand Your Team's Capacity - Identify Team Skills and Strengths - Set Clear Sprint Goals - Break Down User Stories - Estimate Effort - Prioritize User Stories - Align Skills with Tasks - Consider Skill Development - Balance the Workload - Reserve Capacity for Unplanned Work - Regularly Review and Adapt - Retrospective and Continuous Improvement - Communication and Collaboration By following these steps, you can align sprint planning with your team's capacity and skills, leading to more efficient and successful sprints while fostering a collaborative and motivated team.

I normally look at - what got spilled over from previous sprint (part of retro exercise) - what new asks we'd want to deliver - front load spill from previous sprint & within the net new asks prioritize based on impact or any other framework (RICE, MOSCOW)

The development team can consist of a combination of front end developers, back end developers and full stack developers with varying levels of expertise. Moreover, as a product expands, there are usually parts of the stack or the product that an individual in team owns or is most proficient in. All of these factors have to be taken into consideration at the time of planning sprints and matching this with available capacity. One thing to take into consideration is how often developers get a feature first-time-right (FTR). If developers have not been able to deliver a feature as envisioned in the first go, these gaps would be identified by QC and need to be fixed in a subsequent sprint. So budgeting capacity for this becomes important too.

Aligning Sprint Planning with Team Capacity & Skills: Skill Matrix: Create a matrix mapping each team member's skills for task suitability. Capacity Planning: Deduct non-project hours from total hours to assess actual capacity. Assign tasks accordingly. Cross-Training: Reduce bottlenecks by broadening individual skill sets. Open Communication: Encourage members to voice workload concerns & preferences. Buffer Time: Allocate 10-20% of sprint capacity for unforeseen challenges. Team Estimations: Get input from all on task durations for accuracy. Retrospectives: Regularly review & adjust based on feedback.

in delegation of sprint asks the most important part normally is right assessment of dev estimate. Assuming engg. has all relevant product documents (PRD, designs, guidelines, experiment details etc.), they should T-shirt size each ask (use story points) & match it against the bandwidth available for each sub-team based on skills. Accordingly create a view of what all can be absorbed in the sprint & put a clear start & end date.

Sprint goals act as a good motivator, and can be used to illustrate how successful a team is at meeting their objectives--they can also help drive accountability and build a sense of ownership. As for the goals themselves, make sure the expectations are clear. Use other metrics to inform sprint goals, like striving to limit the number of code reviews for pushes (e.g., moving from 3 to 2 to 1 where code changes become less frequent as quality improves).

Communicating Sprint Goals & Expectations: Visual Tools: Use task boards to display sprint tasks and progress. Kick-off Meeting: Begin sprints with a detailed discussion to clarify goals. Regular Reinforcement: Reiterate goals in stand-ups to maintain focus. Accessibility: Store sprint details in a shared location for easy reference. Open Feedback: Foster a culture where the team can freely discuss concerns. Use Analogies: Break down complex goals with relatable examples. Stay Agile: Be ready to adjust goals as needed, ensuring clarity throughout.

I'd add 1 critical point re: communication. Different orgs & teams have different expectation around what sprint success is - dev done, release ready, release done. It's important to align on what is the success of sprint. I have personally seen feature being "release ready" works most efficiently. This makes sure feature is not just developed but is properly tested by QE team & UAT approved by PM/PD teams. Release can then happen per release train frequency of followed in company (which again normally is aligned w/ sprint duration)

Just as prioritisation is a fundamental skill in product management, so is adaptability. Expect and plan for changes as well as when uncertainty becomes reality. When you do need to make changes to your sprint plan, consider it carefully and be sure that the change is substantiated--ideally with data. Be prepared to stand by your rationale for changing the plan and build consensus with your team on why the change was necessary and the adjustments couldn't wait for the next sprint.

Monitoring & Adjusting Sprint Plans: Daily Stand-ups: Hold short daily meetings to discuss what's been done, plans for the day, and any blockers. Sprint Reviews: At sprint end, review completed tasks and assess their alignment with objectives. Retrospectives: Reflect on the sprint's process to identify improvements for next time. Agile Boards: Use boards (physical or digital) to visualize task progress and bottlenecks. Constant Communication: Regularly sync with team members to understand challenges and provide direction. Be Supportive: Offer resources, training, or assistance when obstacles arise. Stay Adaptable: Ready to pivot the plan based on evolving data or feedback. Flexibility ensures resilience in face of changes.

In my experience, while sprint planning, ramp-up time to learn a new skill before implementing any feature is often under estimated or missed. Thus, do additional buffer for tasks such as getting access to tech and learning.

Having a prescriptive approach to matching capacity with sprint items can lead to bad outcomes. If we have too much specialization, it might create blackboxes in engineers who are the only subject matter experts on a topic. If they are unable to work on something due to illness or a vacation, it leaves the team stranded. It's best to let dev teams organize themselves while looking for extremities on both sides of the spectrum. One on hand, we do not want to have one person specializing too much. On the other, we would also want some degree of predictability for engineers. It is a delicate balance.

I firmly believe that the best way to align sprint planning with the team's capacity and skills is by partnering with the team to figure out what is most important for that sprint and strategically. We sometimes assume that the role of the product manager/owner is to prioritize the backlog, create the sprint plan, and define product requirements. It's all of these, and so much more. By partnering with the team, you figure out what else is important - whether it's chipping away at tech debt, getting the team energized by working on a new idea or feature, or spending more time testing.