How can you come up with a "Goal" that obeys Sprint Cadence?
My question is how can you come up with a "Goal" that exactly fits in a "Cadence"?
On a different forum, it was mentioned that these following steps should occur during the planning meeting:
* The Product Owner(PO) first comes up with his vision of what should be achieved through the upcoming sprint. This objective is at this point just a "draft" of the Sprint Goal(SG)
* On discussing further within SCRUM TEAM on reviewing the Product Backlog(PB) further, more clarity emerges
* Based on the understanding of the "draft" and ensuing discussions, Development Team(DT) selects the PB items for sprint in agreement with PO
* Once the PB items are selected, the Scrum Team then crafts the Sprint Goal
* The DT starts the Sprint after work planned for initial few days is decomposed
Here is a Case:
Goal A for current sprint planning(Day 1)- This is what PO came up with for Sprint Planning meeting "Calculate and Maintain attributes at Licence plate number level"
Development Team says: This is not very complex and they could take more user stories from the backlog.
Product Owner: PO says there are no other items in the backlog that are related to this goal
Although I agree to this statement "There is skill involved in negotiating a meaningful increment of value within a fixed time period, but it is an important skill to have( "https://www.scrum.org/forum/scrum-forum/5461/dynamic-length-sprints-scrum" - attached link for reference), I am having tough time understanding how can you accept more items from the backlog without satisfying the Sprint Goal?
What about the Technical Debt? These items are no where related to Sprint Goal. How do you handle them?
Now, back to my question: There is another goal that Product Owner can think of(Lets name it Goal B): "Prompt user when scanned ID is directly/indirectly missing attributes"
So, in Order to make sure we stick to regular timebox (which is one of the core disciplines), Do we then say, Lets modify the goal to say:
"Calculate and Maintain attributes at Licence plate number level and also Prompt user when scanned ID is directly/indirectly missing attributes"
Please share your thoughts on this.
Your general flow of the Sprint Planning does seem reasonable. One thing that I tend to recommend to Product Owners is to also have an idea of not only a "draft" Sprint Goal, but also to examine the Product Backlog and come up with some possible ideas for some sets of Product Backlog Items that are reasonable as a set of work that can support this goal. Using an understanding of the historical performance of the team, the Product Owner can have some ideas of what is likely to make sense and the team can use these to get some ideas. But even with this, the rest of the flow is typically what you describe, but I have seen other approaches.
The case that you describe doesn't seem right to me.
First, the goal of "calculate and maintain attributes at the license plate level" seems very output focused rather than outcome or value focused. Likewise, the goal "prompt user when scanned ID is directly/indirectly missing attributes" feels the same way. Yet again, the final proposed goal of "calculate and maintain attributes at license plate number level and also prompt user when scanned ID is directly/indirectly missing attributes" is not only output focused, but a compound goal. Rather than these output focused goals, I'd look at goals around things like "reduce user input error". I'm not sure how to convert the attributes into an outcome focused goal - I'd have to better understand what you are calculating and maintaining and why, but I think the example demonstrates the goal.
Second, not all Product Backlog Items selected for the Sprint need to be directly related to the Sprint Goal. In fact, I tend to suggest that the Sprint Goal should be achievable if the development team were to get 60-70% of the selected Product Backlog Items to done. In this case, if things happen and the team is unable to get all of the selected Product Backlog Items to done, the Development Team can use the Sprint Goal as a tool to focus on the work that is important. The Sprint Goal could even be related to one or two of the selected Product Backlog Items. In the end, the Sprint Goal is just a tool to help focus the team on an objective or outcome that can cause benefit for one group of stakeholders.
The idea that not all items need to directly relate to the Sprint Goal supports technical debt paydown as well as bug fixes. That said, a good Sprint Goal could be around reducing the number of issues reported to a support helpdesk or improving some reliability measure, which could manifest by selecting a number of bugs across the system or paying down technical debt that prevents effective operation and maintenance of the system.
Great answer Thomas :) I would add, that it is good to add metrics to your goal. Sticking to your example of "reduce user input error", IMO It will be better when we refine it i.e. like this: "Reduce user average weekly input errors by 20%". That goal actually (at least in my opinion), forces us to i.e.:
- ask and gather knowledge of what is the current state (aka starting point)
- set finish line that we commonly agree that determines achievement of that goal
- think differently on how to achieve it, how to measure it, when we should finish some parts / task linked to it in order to be on track and on target, and many other questions that can emerge and help us to plan sprint better and assess what we can ar can not do now.
My question is how can you come up with a "Goal" that exactly fits in a "Cadence"?
Is there any reason why the corresponding selection of work should lack coherence, and fail to give the team a reason to work together during the Sprint?