Classically, we would say our team must start breaking epics in user stories and estimate them. With this total amount of story points, and as we know our team’s average speed, it would not be difficult to estimate when the product could be ready. Please, note:
- An estimation is not a commitment ! I mean, the team estimates the product COULD be ready by that day, but it doesn’t mean that our company defines the release date exactly on the same day! What about giving us the chance to have underestimated the scope , or having any unforeseen event?
Wait, here comes the magic ( and possibly the debate )
As a mature team, our product owner has experience breaking epics in user stories, and she knows exactly the kind of user stories the team expects to work on. They have already done this before, working in a backlog , writing user stories… Our team already realized that most of the user stories they work on have a similar size, they could group their user stories by sizes, and they would find out that it looks like a Gaussian function . Wow , what a surprise! ( or not! )
What does this mean? what are the implications? Well, you smart reader will have probably figured it out : In order to define a possible date, we don’t even need to estimate each user story. We might consider all our user stories to be as big as the “peak” of our normal distribution. Therefore, we would be saving a huge effort of estimating every user story, and actually become even more productive by having more time to develop software.
Even if you, Product Owner, might feel fear of not having things under control following this approach, I have to say that many mature teams already realized and started applying this approach.
What are your thoughts?