“Are we there yet?” We expect kids to ask this on long road trips. However, this isn’t something you want to hear from your product owner, much less your stakeholders. When you know where you’re going, you can often answer how long it’s going to take to get there. If you don’t know, however, you’re going to look like a bumbling idiot to your stakeholders.
In this series on Toxic Agile, we’ve been investigating some poisonous agents that can infect and destroy your agile process. In the first post, we found that unproductive daily stand-up meetings were most likely caused by a disconnected, overly multitasking team. Today, we’ll discuss one of my biggest pet peeves of a toxic agile process – a product backlog in despair.
Symptom Two: The product owner cannot tell a stakeholder when a specific story will be delivered.
There is almost nothing more humiliating then having to tell your client that you don’t know when the job will be complete. Running over-time or over-budget doesn’t just kill your client’s trust in your team, it tarnishes your organization’s reputation. If your product owner doesn’t know when a story will be delivered, it’s probably due to one of the following reasons.
1. The product owner has not added the story to the product backlog.
This may seem like an obvious problem. However, I can’t tell you how many times I’ve seen this be one of the root causes. It is absolutely imperative that the backlog contain the product owner’s vision. If the product owner has a vision for the product, he/she must capture these ideas in the backlog, if nothing else in the form of an epic.
The vision of the product is absolutely essential to a successful product. I believe that this is the product owner’s number one responsibility – to communicate the vision to the team. Without a vision, software developers will not know the direction the product should go. If they don’t know where the product is going, they will make incorrect architectural decisions and fail to find the right areas of volatility. What’s worse, they may spend time writing code in all the wrong places. However, if the product owner outlined the vision, the team can proactively make good decisions.
2. The team is not grooming the backlog on a continuous basis.
The team must properly groom the backlog on a regular basis for it to be useful. This process should happen at least once per sprint. The team should break these stories down into a manageable size. The team should also ensure that each story has a good description, good acceptance criteria, and a good definition of done.
Your end-goal is to know whether or not each story is ready for estimation. Flag each work item that is ready for estimation so that you can filter them out in the next meeting. Your scrum master should coordinate with the product owner regarding stories that need more detail.
3. The team is not estimating the work items in the backlog on a continuous basis.
The backlog is worthless to the product owner if the work items have no associated weight. How long will these stories take? This is a difficult question to ask. However, if keep your backlog properly groomed, then it is much easier. I recommend utilizing a relative estimation process. If you base the estimate off of a relative complexity, then this estimate becomes reliable over time.
Note that you can also apply relative estimates of complexity to epics. Applying estimates to epics will help your product owner decide if it is worth investing time in that direction.
4. The product owner has not racked and stacked the backlog in a priority order.
The product owner has connections with the major stakeholders of the product. These stakeholders are often the people that pay your organization money. Most other people on the development team don’t have the type of insight that the product owner has. Therefore, it is imperative that the product owner order stories in a meaningful, priority order. This prioritization must happen on a regular, consistent basis.
