When it’s time to go to market, you don’t have time to waste on innefective digital product development. Book a free consult to learn how our team can help you reach your goals on time.
This is the second in a two-part series. Read part one here.
Goals can sometimes feel arbitrary, superfluous, or just empty - especially when you are 96 sprints down the line! In the previous article, we discussed the importance of setting both Product and Sprint Goals that matter to the team and the organization. With that baseline in place, we can trace through what that practically means in the day to day events of the team.
Where Do Goals Matter?
Throughout the ceremonies of the sprint, conversation should always center around the goal. Following a sprint cycle, we will look through each of the events.
Sprint Planning
Each sprint starts off with the Planning event. Planning consists of three main questions:
- Why is this Sprint valuable?
- How do we attain that value?
- How will that work get done?
The first question helps solidify the goal. Why are we doing this sprint? What is the end target we are trying to attain? What do we want to be able to do after this sprint cycle is complete?
Similarly, the second question zooms in, building on the goal itself, it asks what work will need to be done in order to complete that goal. What story needs to be broken into smaller pieces? What support work needs to be done to supplement the goal’s hero features? What new tickets need to be made to have a complete outcome of this sprint?
Lastly, the Planning event provides an opportunity for the team to collaborate on how they will work towards this Goal. What they should pair on, what to finish early, and what special cases they need to test. This section directly ties into the Daily Scrum, or Stand-up.
Stand-Up
The Daily Scrum, or Stand-up meeting, provides a daily opportunity to re-evaluate the goal. “The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.”
Whatever facilitation model you use (popcorn, going around the room, or discussion by department), the conversation needs to center around the Sprint Goal. Discussion should open with something along the lines of “What can we do today to get closer to achieving our sprint goal?” Anything outside of this conversation needs to be saved for the Parking Lot.
Retrospective
Retrospectives provide the opportunity to review the sprint for ways to increase quality and effectiveness as a team. The team will discuss what went well, what didn’t, and what they can do differently next time. Specifically, did you hit your goal? What would have made hitting the goal easier? What got in the way of hitting your goal?
Retrospective can be done in a lot of different ways, and everyone has their favorite model. Whichever works best for your facilitation style is probably appropriate, so long as it evaluates the work of the sprint through the lens of progress towards the goal.
Sprint Review
The end cap of every sprint, the Review, again focuses on the Sprint Goal. It typically has three core agenda items as well:
- Did you hit your sprint goal?
- Demo it!
- Based on what you learned this sprint, what should next sprint’s goal be?
If the main point of the sprint was to hit your goal, then the review at the end should mostly talk about that goal. This means your goal has to matter, both to the engineering team and the stakeholders attending your sprint review. Show off to everyone there what you accomplished and why it matters!
Then, before you call it a day, you need to talk about what comes next. You probably learned a lot about the application, the infrastructure, and the user experience while building this deliverable. That, combined with your experienced background in the product, means you have a lot of insight into what should probably be done next. But your stakeholders also know the users in ways you might not! As a group, collectively decide on the next goal for the team to work on. The Product Owner has final say, but this is the venue for anyone to ask questions, raise new ideas, and discuss what comes next.
Even Backlog Refinement
Lastly, though not an “official” scrum event, Backlog Refinement (also known as Backlog Grooming) sets aside time to talk about the Product Goal - the six-month vision for the product. Discuss the features that might be necessary to get that outcome, what they might depend on, and how complex those items might be. As you discuss new roadmap items, hold them up to the Product Goal and see if they align. If they don’t, ask if this user story is important enough to change your goal!
Through each of the events in a sprint, the goal shapes the conversation and keeps the team working together. With this being the constant topic at every meeting and every checkpoint, working a sprint moves beyond pushing tickets and changes into iterative enhancements to the product. Sprints have themes, measurable results, and a singular focus.
How Should You Set Your Goals?
You probably will not accomplish the goal every time. That’s ok! Good goals will probably only be hit around 70%-80% of the time. Anything higher and your goals are probably not ambitious enough. Anything lower and you are probably out of touch with your team’s capacity. Healthy teams will learn from missed goals and celebrate ones they hit!
Aim to build your goals around Simple, Actionable, and Measurable benchmarks. Guide your team to collectively land on a milestone that they can hit, that they can definitively hit or miss, and one that is easy enough for the team to understand. Remind your team of the context and importance of this goal at the open of every meeting and on the top of your Scrum board, and talk about this every chance you get. Every sprint has its theme as part of the Product Goal, and keeping the team’s collective eyes on the target will keep progressing in the right direction.
Scrum is built on Transparency, Inspection, and Adaptation. Working with stakeholders, knowing your users, and strategizing medium-term goals for your product will help you set the right goals, and keeping those goals in the forefront of every part of Scrum makes the whole thing work. Without a Goal, Agile development simply does not work. Start setting Goals that matter, and iterate towards the next level of your product!
