Brokering the backlog - Estimation and manipulation of time to complete in Agile

As the Agile lifecycle progresses and more stories are broken down and estimated there will come a time where a reasonable prediction can be made as to how long it will take to complete a release (or "theme" sub components if an earlier estimate is required). This is simply based on the amount of outstanding complexity points to be delivered within the backlog of stories, divided by the measured (and predicted) velocity of the sprint teams involved in the development.

Step	Activity	Result	Comment
1	All user story cards are estimated for complexity.	Backlog items have complexity estimate.	Epic cards that are not broken down into stories should also be estimated in comparison to other Epic stories that have already been broken down.
2	Velocity of teams is predicted.	Predicted delivery velocity per sprint iteration going forwards.	Team velocity of previous early sprints will have been captured (burn down charts etc) and a prediction can be made with regards to that total "per sprint" (all teams) value going forwards, potentially increasing due to improved learning and more practice or decreasing if resources change etc. can be averaged out to make the maths simpler if a small change is velocity is predicted, for large-scale changes the calculation should be broken up to reflect the steps in the velocity profile.
3	Velocity is complared to Complexity	Calculated result of the number of sprints needed to deliver the backlog	Backlog Complexity / Sum of teams velocity = number of sprints needed e.g. 1150 points backlog / (ave. team 1 velocity 30 points + ave. team two velocity 34 points) = 18 sprints (36 weeks)
4	Backlog is accepted / backlog needs reducing / resource capacity needs increasing.	Total backlog complexity and delivery velocity is either re-factored or accepted.	Either: a) Product owners and Roadmap owners agree that the timescale estimate for delivery is in line with corporate goals (it should be noted that this estimate is not a commitment to delivery and has no contingency or overhead for release processes). or b) Product owners and Roadmap owners feel the timescale estimate for delivery is not aligned with corporate goals. Options are: Reduce complexity in the backlog by removing stories, this requires the brokering of functionality amongst PO's to see what can be excluded from the release. Increase velocity of development by increasing the number of team members, potentially adding whole scrum teams if needed.