Estimation discussions, in my experience, have one very valuable outcome. It's not the story points, but it's the conversations and interactions that happen around the story details. As the team builds familiarity with the user context, business goals, existing framework, technology options, assumptions, and so on, there are valuable ideas that take shape.
Breaking down a user story into tasks (or things to do) helps the team align on the best implementation approach. The pros and cons of an approach are discussed. The trade-offs (what we will not get by following this plan) are discussed. Assumptions are challenged. Risks are identified. Ideation kicks in. The most important outcomes from an estimation session are these ideas, tasks, and questions.
So, if we flip this around, and conduct implementation discussions instead of estimation sessions, then we can expect that estimates will be just one minor detail to derive. We saw in Chapter 5, Identify the Impact-Driven Product, that each feature idea can be rated on a scale of 0-10, based on the cost to build that feature idea. The rating was based not just on estimates but also based on the complexity, technology readiness, risks, dependencies, available skill sets (technical and supporting business functions), and resources (hardware and software).
In order for us to arrive at this cost rating, we can follow this process:
Capture these details from the discussion. This is based on how we identify a cost rating for the feature idea based on these discussions.
On a scale of 0-10, a feature idea effectively falls into two categories: the 0-5 low-cost bucket (doable) which would give us quick wins and nice to haves and the 5-10 high-cost bucket (not doable), which would give us the strategic wins and deprioritize buckets. So, while we evaluate the implementation details, the question we're trying to answer is: what box in the impact-cost matrix does this feature idea fall in?
So, we can do the same for each success metric under a feature idea, as shown in the following image. A feature idea could have many success metrics, some of which could be quick wins some of which could be strategic wins. Some could be nice to haves and some are in deprioritize (depending on the impact score of the feature idea):
We can then evaluate if the feature idea can still deliver value with the quick wins and strategic wins success metrics. We can assess dependencies and so on and then arrive at the overall cost rating for the feature idea. We can arrive at a doable / not doable (within given constraints) decision with a much higher level of confidence.
This allows us to set time-bound goals for developers to work on. The measure of success for product teams becomes the outcomes they have been instrumental in delivering, not the number of story points they have delivered. This can help us to structure teams based on the shorter-term quick-win work streams and longer-term strategic work streams. It also takes away the need to track velocity, and we can now focus on outcomes and success metrics.