My customer’s Kanban team taught me a thing or two about Scrum.
My former PM (a Certified Scrum Master who got us on track doing Scrum in the first place, therefore by definition brilliant and tenacious) always used to try to get us to set a Sprint Goal. Honestly, I thought it was dumb.
It’s supposed to be a unifying shared objective for the sprint, but from the developers’ point of view, we already had a unifying shared objective for the sprint:
“Same unifying shared objective as every sprint, Pinky: deliver working software!”
Seriously, since we the team didn’t control the order of items on the backlog, it didn’t make sense. We couldn’t be certain the top n items would have anything in common with each other. Sequencing the backlog properly is a difficult enough exercise—trying to take stakeholder priorities and technical dependencies into account—without also (it seemed like we were being asked) shuffling it around just to satisfy some arbitrary desire for a theme!
So, we never did it. Our PM/CSM finally quit asking. We delivered stuff. It was fine. My team loved doing Scrum and they’re still doing it today, goal-free.
And then the other day one of my customer’s teams showed me—without really meaning to—exactly how a Sprint Goal is done and what it’s for. It was a perfect moment of clarity for me which I’m not sure they even noticed. They just did it.
“Hey, guys, we had an awesome show-and-tell last week. Our stakeholders were really excited about what we delivered and couldn’t wait to start using it.”
“If we were to think about what we want to do for the next show-and-tell, given the stories we’re looking at from the top of our backlog, what do we think we could demo for those stories that would really wow everyone?”
Isn’t that what a goal is? Envision your desired end state, and then work back-to-front to figure out how to get to it. Why didn’t my team and I think of that? There I was, trying (and failing) to do Big Goal Up Front, in a process that’s intended to be agile and driven by outcomes, not planning. Old waterfall habits die hard, don’t they?
My customer’s team got this right and they aren’t even trying to do Scrum! (They’re basically a Kanban team, only timeboxing because they synchronize their development and release cadences with other teams on their shared enterprise product.) They get awesome benefits from the simple question, “what do you think we could demo?”:
- It shapes the decomposition of epic-sized stories into iteration-sized ones while keeping the focus on stakeholder value.
- It gives the team a meaningful unifying shared objective, also focused on stakeholder value.
In a way, the team still has the same iteration goal every time:
“Same goal as every iteration, Pinky: make the show-and-tell awesome!”
Where it varies is in the details: the plan for the show-and-tell is based upon the backlog and its priority, as it should be.
I think it’s brilliant. Easy to understand, easy to plan, easy to execute. Scrum or not, I’ll recommend this approach from now on!