How to Set Realistic Sprint Goals for Teams

I still find Marketing Sprints the best way to run a marketing team. Basically you work in 2-week blocks (like an engineering sprint) and all goals are broken down into 100% doable jobs to be done. Say for example you want to try and get the team on more podcasts as a guest. Ex: Bad sprint item: “Book 10 podcasts this month”. This is a result but not 100% controllable. Good sprint item: “Create three possible pitch options and review with management”, “Send out 100 pitches”, “Create Notion doc of 50 good fit shows and write notes on each so pitches will be personalized” etc. The idea is you need to take big goals and break them down into all the constituent parts needed to execute them. It takes some vision from management and it takes some learning and adjusting as you go. But as a result you get a great 360 on the work of your team. You encourage high tempo output in a creative department. And if you do it right, every item is always accomplishable, so there isn’t this nebulous zone between tried and actually executed. From running this with teams through the years (I think I've done maybe 5-6 workshops now on this), here are some learnings… 1) Most folks pack in too many things initially and only hit ~75% of their tasks. Like completion rate in engineering sprints, it takes some calibrating. An important note, however, is that some jobs won’t get done because of contingencies. “Well I wanted to get this up, but I am still waiting on design”. It’s important contingencies are labeled and planned ahead of time. We did this in JIRA at Bonjoro and I used simple tagging. 2) I find marketing sprints really only work with good management pre- and post-sessions. It is the job of management to give the stamp of approval on the tasks that need to get done to execute towards a goal. It’s collaborative with the team, but management is saying “Yes, this makes sense for X goal”. If the team member hits 100/100 of the tasks and the end goal isn’t made, that is a management/leadership issue. Similarly, with marketing sprints, we take 2-3 days post sprint to review what got done, any results, any trends or blockers, before setting the next agenda. Folks that implement marketing sprints without the post-sessions I find hit problems. 3) Set Micro-KPIs at each leg of the race. Say you want to build a growth engine via top-of-funnel content with app partners. The first sprint is going to be assembling the list of the right fit folks. Here what disqualifies a team? What are the size, audience or fit benchmarks? Next you are going to do a sprint pitching some collaborations. What is success here? Set some KPIs around response rate, or willingness to invest or creative bandwidth to contribute. The idea is you don’t want to spend a quarter pitching and then report back, “Yeah, it seems like folks don’t want to make a podcast or newsletter together”. You want to discover the objections or blockers quickly, then pivot your approach on the next sprint.

Pairing Velocity and Capacity Planning in Scrum Velocity is a common metric for sprint planning in Scrum. Teams typically use the average story points completed over the last several sprints to forecast future work. Let's set aside the "flaw of averages" (read my earlier post on using confidence intervals instead) and assume teams reading this post just use their average velocity. Relying solely on velocity can cause overcommitment when sprint durations fluctuate or team capacity changes. That's why capacity planning can complement velocity to improve planning accuracy. Pairing velocity with capacity planning creates a realistic, adaptable approach to sprint planning. Let's talk about why - and how - it works. Velocity Velocity measures the work a team delivers in a sprint, expressed in story points. It would be common for a team averaging 20 points to use that as a benchmark for future sprints. The risk is that velocity doesn’t adjust for sprint-specific factors like holidays or planned absences. That can lead to unrealistic commitments. Capacity (Availability) Capacity planning evaluates actual team availability for a specific sprint. It considers sprint length (e.g., 9 workdays instead of 10), planned absences (vacations, holidays, etc.), and working hours per developer. Team availability is converted into "developer-days." For example, a 5-person team working 8 hours daily for 10 days has 400 available hours max. Shorter sprints and absences reduce this capacity. Why Combine Velocity and Capacity? Realistic Commitments Velocity provides a stable benchmark, but capacity planning adjusts for unique sprint conditions. For example, if a team’s velocity is 20 points for a 10-day sprint, a 9-day sprint might lower this target by 10% to 18 points. Balanced Workloads Using velocity alone risks overcommitment. Using capacity alone risks underutilization. Combining them mitigates these risks and helps make commitments achievable. Adapting to Change Velocity anchors plans in proven performance (empiricism), but capacity planning accounts for variability (e.g., holidays, absences, onboarding, etc.). How to Pair Velocity with Capacity 1) Start with historical velocity as a baseline. 2) Calculate available developer-days, adjusting for holidays or absences within each sprint within the forecast timebox. 3) Scale back velocity to match capacity (e.g., if capacity is 90% of normal, reduce the velocity target by 10%). Benefits of Pairing Predictability: Commitments align with capacity for consistent delivery. Transparency: Stakeholders gain visibility into achievable goals. Flexibility: Teams adapt to sprint variations without risking outcomes. Deliver Predictably in Dynamic Conditions Velocity is a valuable metric but it doesn’t account for short-term variability. If calculating confidence intervals feels too complicated, then use capacity planning to fill the gap - creating a planning process that’s both empirical and adaptable.