Historical data and trends can be used for discussion in the Sprint Retrospective. Keeping this information visible helps the team think about it. Similar to how a team may track their velocity or automated test coverage over time, a team can also track Sprint Goal achievement over time. Make the Sprint Goal a team measure and keep it visible in the team space.This can help improve team collaboration. The facilitator can ask the team at the end of the Daily Scrum how they feel about the likelihood of achieving the Sprint Goal, if any adjustments are needed to the daily plan to refocus, or if scope needs to be negotiated. Development Team members often give updates about the Product Backlog Items they are working on, and the Sprint Goal is never discussed. Teach the team to talk about progress towards the Sprint Goal in the Daily Scrum.Write the Sprint Goal on or near the Scrum Board. Remember we have to actually pay attention to it to help provide focus. 3 - The team doesn't pay attention to the Sprint Goal during the Sprint. On-board new market segment.Enable new market segment to purchase Service Y. Improve performance.Increase page load time by X%. Here are some examples of unclear Sprint Goals and modifications to make them clearer.Įnhance shopping cart functionality.Streamline purchasing process to enable an increase in conversion rates. This is also a way to help encourage team ownership. During Sprint Planning, use a consensus technique to confirm everyone's understanding and commitment to the Sprint Goal.This helps reduce subjectivity, or opinion. During Sprint Planning, ask "how will we know if we have achieved the Sprint Goal?" If we have different answers or puzzled looks from the Product Owner or any Development Team members, then we need further discussion and refinement of the Sprint Goal.Here are a few tips for creating more clear Sprint Goals. When we get to the end of a Sprint, is the entire team in agreement on whether or not the Sprint Goal has been achieved? If not, the Sprint Goal may be too vague. This could mean working on continuous improvement items. This could mean delivering more functionality. If the Sprint Goal is met before the end of the Sprint, professionals will figure out what else they can do to contribute in meaningful ways. If self-organizing, empowered teams are to be effective, we must believe that people are committed to doing their best. This sentiment reminds me a bit of command-and-control. We think the team may not work as hard if the challenge isn't big enough.Yes, coming up with good Sprint Goals is hard. When I teach Scrum courses, I often hear that teams consider their Sprint Goal to be "complete every PBI." This is the equivalent of not having a Sprint Goal at all. We try to encompass every Product Backlog Item (PBI).If it feels impossible to choose one, perhaps our Sprints are too long and do not provide the business the opportunity to change focus and direction frequently enough. We end up with waste due to context switching and little room for the work to emerge as we learn. When we cram too much into a Sprint, we are setting ourselves up for failure. When we are ordering the Product Backlog and doing Sprint Planning, consider both cohesion of the work and the top priority (singular) initiative. We are working on multiple unrelated projects or initiatives.
Here are a few reasons we end up in this situation and suggestions for how to think differently. achieve X and Y and Z), we are splitting focus and not allowing much flexibility. Here are four common problems with Sprint Goals and a few tips for improving them. The Sprint Goal helps provide focus on an objective we want to achieve and allows the flexibility to negotiate the work to achieve that objective.Ĭreating a clear Sprint Goal can be challenging for Scrum Teams. When we create the Sprint Backlog, there is an expectation that work will emerge during the Sprint.
Remember that software development is complex, and we cannot plan perfectly for the unknown. If we have a Sprint Backlog, essentially the plan for the Sprint, why do we need a Sprint Goal? It provides guidance to why we are building the Increment. In a previous post describing challenges to creating a done Increment, I identified a lack of clear Sprint Goals as one of those challenges. According to the Scrum Guide, the Sprint Goal is an objective to be met by the Sprint through the implementation of part of the Product Backlog.
Search Professional Scrum Certificate Holders.Professional Scrum with User Experience.Professional Agile Leadership - Evidence-Based Management.