Lately, I’ve been thinking about the parallels between rugby scrum and agile scrum, more specifically with what comes before. There are 4 steps that have to happen before you start a scrum in rugby, otherwise the scrum will simply collapse and you have to start all over again: Crouch. Touch. Pause. Engage.
Obviously I don’t mean this literally, but for me, these four steps align with preparing a solid backlog. My work in the past few months has been focused on evaluating some items that we are considering to build in our next product release, they are asks from our users that are not at all or only partially defined, we know that there is a need, but we don’t yet know how to meet it. In order to figure out how best to tackle these features, we decided to form a dedicated team, exploring our options and coming up with solutions that we can then turn into actionable epics and user stories.
This is the first time that we have gone with this approach, so it has been an interesting discovery of trial and error before we came up with a general approach that so far has helped us a lot in structuring our efforts.
Get into position, understand who is involved, who is on the team and what their role is. We needed to fully understand our problem statement, define our goals and success criteria and I wanted to have a clear idea of our ROI, what are we getting out of this that warrants the investment. From there, it was time to work out exactly what the current processes are, which parts work and which parts don’t and where we think we might want to focus our efforts.
Getting a first sense of how the users feel about our proposed solution was very important to make sure we’re on the right track. This is not a fully baked ready to roll backlog of precise features, it is more of a general approach, that outlines which problems, extra steps or issues we are removing, maybe show a couple of rough mockups of what the new process might be and how it would impact their day-to-day. We kept it general enough to allow for their suggestions, but defined enough to be able to clearly explain the solutions we are suggesting.
When I say pause, I don’t mean just stop what we are doing, this is really more of a chance to reflect. We use this time to incorporate our user feedback into our design, further define our solution and do a deep dive into technical possibilities and limitations. We spend a significant amount of time here, weighing up technical complexity vs user experience, the ideal solution vs the realistically achievable approach… The variables really depend on the complexity of the feature. What I also focus on here is documenting our decisions and recommendations, and most importantly; document the “why” it will be immensely helpful for others.
Once we have figured out what we want to do and how we want to do it, we are almost ready to start scrumming. Now, all we need to do is transfer the information to the relevant scrum team. Since we have been working on multiple features that cannot be achieved with just one team or even just one product owner, this piece is really crucial to get right. I learned that the hard way for our first feature, when we kept on getting drawn into the discussions time after time. Being out first attempt, obviously it was not perfect, but I think we learned from it and have a much better handle on how much detail and guidance we need to provide.
I think. I hope. We’ll see…