This is a guest post by Srđan Stanić, a leader, software engineer, and fitness nerd with 14 years of experience in software engineering and 6 years of leading engineering teams. His super-power is transforming chaos into calm.

Want your own leadership profile like this? Try the BUNCH leadership coach!

When it comes to planning sprint work and setting goals, I have made all the mistakes you can imagine:

  • running sprints with almost no planning and no retrospectives
  • adding tasks to sprints without a clear specification
  • prolonging sprints to complete the planned work
  • changing goals mid-sprint
  • accepting scope that we knew was impossible to finish within given constraints hoping for a miracle to happen by the end of the sprint

I’ve also learned from failing at these things – both on goal-setting and leading teams. From guiding principles to dealing with “unplanned” work and the challenges in between, I’ve had to learn by doing (like most managers), and I’m happy to share the results.

On guiding principles for planning work and setting goals

Number one is to create an atmosphere of trust and psychological safety where you can get reliable feedback on what is achievable and what is not.

Number two is to break down work into items that don’t take more than a few days to complete – higher than that, and the estimates are less reliable because there is a higher chance of hidden unknowns, and there is more risk of being late.

On team sizes

I’ve led software project teams and software product teams (design, development, QA) up to about 20 people. Trying to lead too large of a team (more than 10 people), where I was the only person with a primary focus on planning work to be done and ensuring it’s delivered as planned just did not work

As a result, projects had incomplete specifications, vague estimates, moving deadlines, and there was a constant feeling of being late with deliveries. The first attempt to address this issue was to delegate some of the planning and progress tracking on the developers and developer assisted tooling – it did not work – some developers are capable of handling multi-role projects, but most aren’t, and that’s ok. 

Once we started to have more team leads and project leads, things got better. The literature says an ideal team size is between 4 and 9 – going beyond is a stretch. If you have more than 9 individual contributors in a team, make sure to have more than 1 person leading projects. 

On ambitious vs. realistic goals

Both ambitious and realistic goals have their place in planning our work. I think it’s more effective to be ambitious about the impact of work in the long term and to be realistic about the scope of work that we can do in the short term

Try the Bunch leadership coach to get daily leadership wisdom with your morning coffee and become a better leader in 2 minutes a day!

To try to give an example, let’s say we have a content marketing strategy to write 10 blog posts in the next month and achieve 100.000 unique visits. If we usually write 5-7 blog posts in a month and get on average 60.000 unique visits, then achieving our goal sounds like a stretch and probably will be a source of stress and result in low-quality posts. 

But if we focus on the uncomfortable goal of 100.000 visits and think about how to get there with the realistic number of posts, we might take some time to analyze what we have been doing so far, what worked, what didn’t work, experiment a bit, and try new approaches. 

Eventually, with a new strategy, we might write 5-7 blog posts while getting 90.000 unique visits. So with the same realistic amount of work, we have achieved a higher impact. But it also probably took us a couple of months to get there.

On collaborative goal-setting with the team

One thing that comes to mind from OKRs is to set high-level goals for the team and then support team members in defining their own low-level goals, which will contribute to the high-level goals. 

With less skilled or experienced team members, managers will need to be more involved in defining their goals. Either way, team members should have a say on their goals to increase motivation and commitment. The worst thing a manager could do is to hand down the goals without asking for feedback or input from the team.

On “unplanned” work

A big hurdle I’ve learned gets in the way of our team is not leaving room within the sprint for “unplanned” work. When this happened, the velocity was lower than planned because of critical bug fixes, urgent issues from high profile clients, and infrastructure challenges. 

Solutions entirely depend on the circumstances. If you have a stable team that works in sprints, track the team’s performance across multiple sprints and then accept their velocity for what it is – plan only as much feature work as the team managed to do within earlier sprints.

If the team works with kanban or the team is project-based with multiple ongoing projects, you might want to have a dedicated team for “maintenance” issues, but make sure to rotate people in and out of this team because this work can often be grueling. 

On adjusting goals

Experienced team members will usually already be aware that goals change, projects get canceled, and products iterate, but less experienced ones might be surprised and demotivated by sudden changes in direction. 

A guiding principle is to manage expectations up front. The goals we choose for ourselves are based on the current circumstances and information available. As time passes, the circumstances will change and new information will appear. If the assumptions we made when we defined our goals turn out to be correct, we will happily keep our goals, but if they don’t, we will need to course-correct.

Another obvious but relevant principle is to do the prep work. Invest a reasonable amount of time upfront in preparing the work to be done (market research, specifications, user testing) so that once you start the work (developing software in this example), it is much more likely you are building the right thing. 

On chasing deadlines

When a deadline is nearing, and we haven’t completed as much work as we planned, one option that is often on the table is reassigning people from other less urgent tasks to the one that is late. When considering this solution, we need to remember that people are not robots and that shuffling them around has performance costs – when people switch tasks and projects, it might require one or more of the following:

  • more communication and synchronization in the team when new members are added to an ongoing project
  • time for context switching for the person being reassigned
  • if the added team member is less skilled or knowledgeable on the topic, they will need additional assistance from the current team members; thus, the current team members will be less productive

All of this can cause productivity and motivation to dip, and sometimes it’s worth the price, but not always. Evaluate how important a task at hand is and whether trying to finish it with additional workforce is worth it.

On frameworks for goal-setting

There are many mental models and frameworks around goal setting. Some are more useful than the others, depending on the situation. Here are some frameworks that I have used and found effective: 

  • SMART: (S)pecific, (M)easurable, (A)ssignable, (R)ealistic, (T)ime-related – this framework is helpful regardless of the team size or organization structure.
  • OKRs: (O)bjectives and (K)ey (R)esults – this framework requires a significant time investment across the organization. Still, if followed consistently, for larger organizations, it might pay off in a big way.
  • Moonshots – often it’s worth thinking about how to 10x your impact – and usually, it’s unimaginable at first how you might achieve that. The important part is that it’s impossible to 10x impact without rethinking your current strategies completely. The exercise itself might result in changes and significant improvements in impact that wouldn’t come from the usual iterative approach.
  • Getting Things Done by David Allen – perfect for each team member to get self-organized and to help them stay on top of things.

And there you have it – my top tips for setting goals that your team can actually buy into. Let me know if you’ve tried any of this, and feel free to connect on LinkedIn or in the Teams at Work Slack group!

Ready to level up as a leader? Try Bunch – the AI leadership coach, and become a world-class leader in 2 minutes a day!