This is the way it should be, focusing on the Sprint Goal, rather than chasing a pile of tickets. Ive seen many teams not have a Sprint Goal, or not know what it is.
Not that Maarten is paying me or anything (or not enough, if he is) but that's one reason I pretty much inhaled his book. It represented a sort of 'true north' rather than being beset with the hobgoblins of 'correct' process.
This is by far my biggest complaint with the Scrum Guide. It specifically talks about the creation of a Backlog via Refinement, which then "forces" teams to create a Sprint Goal by choosing Backlog items. The majority of the teams I've worked with choose the Backlog items, then create a Sprint Goal that relates to what they just chose. Makes no sense to me. It's totally reversed from how it should be done...and how you did it here. I strongly believe teams should be creating Spring Goals months in advance, then choose the Backlog items that help you reach that goal. Create your Product Goal (3 months) and then associated "stepping stone" Sprint Goals. Only then should you choose Backlog items that help you reach your Sprint Goals...not the other way around.
I like this idea. How do you estimate when there is so much unknown?
You don't. You do a spike, and let that guide the discovery of the unknown.
The key part is that the spike is small, e.g. max two weeks, preferably even within a week.
This is the way it should be, focusing on the Sprint Goal, rather than chasing a pile of tickets. Ive seen many teams not have a Sprint Goal, or not know what it is.
Not that Maarten is paying me or anything (or not enough, if he is) but that's one reason I pretty much inhaled his book. It represented a sort of 'true north' rather than being beset with the hobgoblins of 'correct' process.
Great post! Language wise, I can go a step further and agree with Uncle Bob: **sprints never fail** as we always learn valuable information from them.
I dislike the 'never fail' philosophy.
They do fail, and you do learn the most from failure.
There's nothing wrong with failing.
This is by far my biggest complaint with the Scrum Guide. It specifically talks about the creation of a Backlog via Refinement, which then "forces" teams to create a Sprint Goal by choosing Backlog items. The majority of the teams I've worked with choose the Backlog items, then create a Sprint Goal that relates to what they just chose. Makes no sense to me. It's totally reversed from how it should be done...and how you did it here. I strongly believe teams should be creating Spring Goals months in advance, then choose the Backlog items that help you reach that goal. Create your Product Goal (3 months) and then associated "stepping stone" Sprint Goals. Only then should you choose Backlog items that help you reach your Sprint Goals...not the other way around.