In How to Predict When the Team Will Complete a Specific Backlog Item, Part 1, I said there was no way to accurately predict an estimate for a specific backlog item more than a month away. I did suggest several options if you want to go through the motions, but there's no accurate answer to that question.
I also said I don't blame the managers for wanting to know. But instead of placating the managers and trying to estimate, consider starting with this question:
How do you plan to use this information?
That might offer you ways to answer the question that does not require any prediction. Here are the kinds of answers I've seen:
- “We have to fund the project up until we get that functionality.” That's a project portfolio funding problem.
- “A Very Important Customer wants to know when they can expect that feature.” That's a backlog/marketing/sales problem.
- “I just want to know. I'm paying for this project. I want to know what to expect.” That's an organizational problem, specifically with a lack of trust.
Let's start with the project portfolio and the funding problem.
Funding Problems
In my experience, organizations use several funding models:
- By project, where they assign a team to a project (or several teams for a program).
- By product, where they assign a team to a product for a long period of time.
- By person, where they take one person from here and one person from there, etc, to create enough people to work on the product. I'm not going to dignify that with a discussion. That's a prime example of resource efficiency, which does not work. No one can predict any backlog item, not even one this week if people don't collaborate as part of a team.
Those first two funding models succeed (the image is from Manage Your Project Portfolio) because the teams have a single coherent objective, no interrupting work, and they deliver value on a regular basis.
Every time the team delivers, the leaders can reassess the ongoing value of the project or product. If your managers want to know “when” for some feature set, they probably want to know when they can expect to stop funding those efforts. They think the value of the project or product will rapidly diminish after that feature set.
Here's the bad news. If they're already thinking that way, there is little value now in the current backlogs. Their best bet is to re-evaluate all the feature sets in the various backlogs and see if there is still value in the effort. They should consider stopping the effort (project or product) now. Remember, just because a given feature set has, say, 30 features, the customer might not need all of those features now. The product might be just as good if the team can stop at 10 features.
But maybe your organization has a more limited customer set and someone needs to know “when.”
A Customer Wants to Know When
Under normal circumstances, when customers want to know when for various backlog items, I choose which roadmap to use. See the series that starts with Why Car Roadmaps Are Not the Same as Product Roadmaps, Part 1. The more innovation we expect in a product, the more I want to use the possibility-oriented roadmap as in Help Your Customers React the Way You Want with These Roadmap Options, Part 3. And, make your customer a partner, not a stakeholder. (See How to Create Partnerships Instead of Using Stakeholders.)
What if a customer says, “I'll buy that, but only if the feature set is done”? What do you do then? I see these choices:
- Rank that feature set next. (Or enough of the minimums in that feature set so the customer will buy.)
- Decide if that's where you want your product to go. You might need to ask, “What would you give up to have that now?” Or some other way to discuss the relative tradeoffs of which features and when. However, as a product leader, if you don't want this product to go in that direction first, you can say, “Thank you for your feedback, but we're not focused on that feature set right now. Here's our possibility-oriented roadmap.”
- Or, if you're like me, you might ask, “Great. How many of our product will you buy and when can I see a purchase order?”
Product leaders: Address the relative value of what's in the roadmap and what kind of a roadmap to show the customer.
Now, we get to the meat, where the manager needs to know to feel good about the development.
“I Need to Know”
I've used the lunch analogy in Part 1 before. And even when I used that, some of my managers said, “I just need to know you're making progress.”
Aha! I needed to demo more often. If your team can offer visible progress at least once a week, many managers will forget their “need” for you to predict something more than a few weeks away. (This is the same problem as in Want to Be More Effective (and Agile)? Rethink Three Classic Management Assumptions.)
The demos build trust—and might offer the team feedback on the product and the product leader feedback on the backlog.
I don't recommend you placate your managers. Instead, learn why they want you to predict something more than a few weeks out. That's not reasonable for you to do and does not offer them the value they think they need.
When we ask managers (or anyone else) how they plan to use the information, we are more likely to offer useful data. That's why we have these conversations.
Conversations Matter
The conversations matter. Assume the person asking has a good reason for asking. And the more you can build your influence with that person, the better the conversation will go.
Even when you know the request itself does not make sense, honor and discover the reasons behind the request. That will allow you to offer different information that does make sense.
Well, this post is too long, too. I'll do a summary of principles and tips to wrap this series up.