Feature Estimates - How detailed?
Hi,
For each of our releases (usually quarterly) we base our target of release content on features that will be delivered.
Typically we estimate the features at a t-shirt size and compare to available capacity to come up with what our planned scope should be. We then have a subset of features we can analyse further and recheck estimates before the final target is set.
The problem we are facing is that the business is asking for much more analysis/certainty around these t shirt sizes so we can make more informed decisions.
This is a real drain on resource as typically we have 50-60 candidates up front we need to t shirt size.
Does anyone have any tips or tactics around how this could be better handled or any experiences they have had similar to this?
Thanks
The problem we are facing is that the business is asking for much more analysis/certainty around these t shirt sizes so we can make more informed decisions.
Who's "we", and what decisions are being made which ought to be better informed?
Remember that the purpose of estimation is for Developers to get their arms around how much work they can take on in a Sprint. Everything else reduces to value delivery and empirical process control.
Thanks for the reply.
"We" is the development department. And the 'pressure' is coming from our product department who are ultimately having to make the calls as to what from their long list of features should be targeted for the next release.
Appreciate priority should ultimately determine what goes in but we have a constant battle where these priority decisions can't be made until estimates are known. Hence the request to now estimate this long list in lots of detail.
And the 'pressure' is coming from our product department who are ultimately having to make the calls as to what from their long list of features should be targeted for the next release.
Why isn't the Product Owner ultimately making those calls?
What you've got sounds more like a product ownership issue rather than a problem of estimation. The purpose of estimation is for Developers to get their arms around how much work they can take on in a Sprint.
A Product Owner would be less concerned about estimates and more about the empirical evidence of value being delivered each Sprint. He or she would want delivery to be predictable from that evidence; instead you've got a department that's trying to be predictive.