When I set out to write this article, I wanted to capture the challenges I had faced during several initial product backlog refinement (IPBR) sessions that I had facilitated — and how I was able to overcome them. But as I penned my thoughts, I felt that it would be better to share with you a great approach for conducting a meaningful IPBR. I will save the challenges for the next article.
A typical scenario goes something like this: After an exhaustive discussion with the product owner (PO), the team comes up with a list of user stories (also some epics, a few spikes, and some architectural stories). To work on these stories, the PO must develop a release plan. The problem is not as simple as it sounds. One approach that many would suggest is to size the user stories, use yesterday’s weather (Beck and Fowler, 2000), and forecast a schedule of completion for the project.
Imagine a situation in which the PO says, "I have a big trade show coming up in the next two months, where my company is putting up a product demo kiosk. And, just for information, my VP is personally tracking the project. So, I need to know which features are being delivered each sprint so that I can foresee the possible release dates. I would also like to see a few high-stake features that would be demoed in the trade show. It means my job to me."
The PO is hinting at two things: sprint (release) scope and value delivered. How does the team crack this code? The most intuitive thing to do is ask the PO to prioritize the features, followed by the team sizing the stories based on the team's historical velocity (or assumed velocity), then forecast a release plan.
This is definitely the way to go, but this still seems to be a 30,000-foot view. I would suggest (and I have validated this in several scenarios) that you not jump into it straightaway. We need to think through several aspects before we forecast the release plan and align with it.
Some of the considerations are:
- Order of usage
- Risk reduction
- Knowledge creation
I adopt the following two-step process to arrive at a prioritized list of user stories that factors in all of the above.
1. Reduce risk and prioritize
is one of the most widely used (sometimes abused) term in an Agile development environment. You can prioritize in different ways. I will refrain from delving into this subject now; more on this later.
One important point to note is that it always helps to talk about business value in conjunction with technical complexity. Think about it. A very high business value item is prioritized at the top in the product backlog, without thinking of its technical complexity. When the sprint is about to start (or worse, after the sprint starts), we discover too late that the story has an inherent technical complexity. We may be at risk of taking a hit to the sprint goal. Hence, always talk about the technical complexity associated with the stories vis-a-vis the business value. It helps to discover the potential technical risks and forces you to identify spikes and resolve them.
I generally use the four-box technique to achieve this. This is a very lightweight and effective method for early-risk discovery. The two stakeholders, the PO and the team, discuss and decide the position of each user story on the quadrants for their respective parameters (the PO decides the business value and the Scrum team decides the technical complexity). Each user story finds a place in one of the quadrants and represents the relative business value and technical complexity with regard to each other, within and across quadrants.
2. Identify dependencies
Which quadrant (circled numbers) in the above diagram should you target for execution first? It is interesting to note how the teams respond to this. The response is divided between one of the two obvious choices: Quadrant 1 and Quadrant 4. The team is also unanimous in its opinion that US1 and US2 are such stories that, if possible, should never be developed.
Without getting into the interpretation of their choice, let’s try to understand what it means in the current context. For our discussion, let’s assume that we want to execute Quadrant 1 first. Are we ready to take the plunge? Can we say that sprint 1 for us would consist of US9, US7, and US8 (in this order), provided that the velocity considerations are favorable? The answer is no. What if US1 depends (needs) US2 for development? Therefore, we need a mechanism to depict the dependencies between the user stories.
I use the approach below to establish dependencies between the stories and call it dependency mapping
. Below is the draft prioritized list of user stories derived from the four-box technique. Now we try to map the dependencies/prerequisites for stories (on other stories). The convention I prescribe is that the arrow head points to the prerequisite item.
For our understanding, let’s say the above dependencies exist between the user stories.
- US9 needs US2.
- US7 needs US3.
- US3 needs US9.
Considering these dependencies, the priority list is revised. The new list looks like this:
Are we ready to go? To an extent, yes. However some teams would still like to give some thought toward creating an infrastructure that can be reused; hence, priorities may be revisited. It's a deeply satisfying experience every time I take a new team through this. The team feels more confident, and by the time the final priority list is charted, there is sound buy-in to the plan. This is the cornerstone to a successful Agile project. A release plan based on this list would be more logical and grounded in reality.
Try this out if you find it interesting, and do let me know if it works for you!