On a recent engagement, we found it difficult to do our Sprint planning following the structured product backlog the team had prepared. This was mainly due to the fact that a very successful Release Planning session had changed the direction we first took.
We were left with a product backlog that was not really “cut” in the right way… The backlog items were not useless, they just didn’t really help us plan our Sprint the best way.
I suggested that we didn’t spend too much time trying to shoehorn these backlog items into our Sprint, and that we didn’t spend too much time reworking the backlog before we got started.
Instead, I proposed that we did DDSP, that is drive our Sprint planning from the the angle of:
“Without looking at the backlog, what would we want to be able to demonstrate at the end of this Sprint? What scenarios would we want to play back to our stakeholders during the show and tell meeting? What should the customer experience of these features look like?”
These few questions allowed us to create on the fly a number of objectives for the Sprint ahead which in effect became our backlog items. This was coupled with a light definition of done conversation which helped us swiftly define our tasks and estimate them.
I have used this technique on many occasions where the conversation was at risk of being centered too much on delivering user stories without the underlying objective of showing progress towards valuable business solution.
The backlog and its items get revisited and changed in many ways during Sprints: they align a lot better to the way the Release Plan has been discussed, both in terms of content and how they expose the business value.