Resetting Sprint Goal
Hello,
In our project we use sprint goal. I have 3 questions :
1. Should we reset Goal number of every sprint to 1 ? or its good to increase the goal number to keep track of original goal if the JIRAs in a particular goal are not complete ?
2. If we have one unfinished goal from last sprint, should we make it a high priority goal in next Sprint ?
3. Should we prioritize goals in JIRA ?
Bidhu, you say you are working with multiple Sprint Goals.
I am curious why you believe establishing Sprint Goals into the future promotes agility?
In our project we use sprint goal
Are you sure that's what you're doing? The Scrum Guide describes a Sprint Goal as a coherence.
I have never seen a Sprint Goal that would be reset to 1. Can you provide an example of these? I'm saying this because it seems like your definition of Sprint Goal is not the same as that provided by the Scrum Guide. From the section that describes Sprint Planning
During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.
I'm not saying that you are incorrect in your definition but I can't visualize a goal where you would "reset Goal number of every sprint to 1".
For our project we have Goals. Example : In sprint 1 we have Goal 1 - Payments processing, Goal 2 - Policy processing etc. Now lets say we have 5 JIRAs each for each of these goals and we completed 9 of them. 1 JIRA is left from Payments processing which will move to Sprint 2. In Sprint 2, we have Endorsement processing. So we are assigning Goal 1 for Endorsement processing and Goal 2 for Payments processing in Sprint 2.
My point is should we do like this or we should not change the Sprint goal numbers ? Thoughts ?
My point is should we do like this or we should not change the Sprint goal numbers ? Thoughts ?
Were these 2 Project goals included in your Sprint Goal ? If yes, then whats your thought on the outcome Sprint ?
Are you using these numbers for priotizing your backlog ?
From your explanation I understand that you are creating multiple Sprint Goals for a single Sprint. To me, it seems like this would hinder the team because it is splitting their focus. I have found that the usefulness of a single Sprint Goal allows the Development Team to focus their efforts on a single target. Splitting their attention is in essence the same as having too much work in progress. In your case, it seems that the team focused more on the Policy Processing Goal than on the Payments Processing Goal. Why did they make that decision? Why would they put themselves into a position where they had to make that decision?
Another issue that having more than one goal encourages is that the team is not working as a single group. They are working as 2 subteams. I would expect to hear them start to complain about having to attend Daily Scrum and listen to things that do not concern them since half the team is talking about the other goal. Or worse, split the Daily Scrum into two Scrums where each is focused on a single Sprint Goal.
If I were Scrum Master for this team, I would be using this situation to discuss whether their current practice is causing problems instead of how to decide what to do with each Sprint Goal.
There is only one goal every Sprint. Multiple goals in a Sprint create lack of focus. Watch this youtube video to give you insights on how to create a good Sprint Goal.
What is the expected outcome from investing a single sprint in completing those Jira items?
If the work is sufficiently complex, it might be useful to consider the higher goal. Rather than payment processing and policy processing, perhaps these initiatives all contribute to a single more important achievement, such as "customers are able to do ..."
If you want a more outcome- focused Sprint Goal, and are able to release early enough in the sprint, you might even have something based on how customers or users interact with what is built; like "x% of customers use ... to do ..."
In trying to achieve this, you might reveal other problems you need to solve; for example maybe the Sprint Backlog isn't focused enough