Following Agile Principle in Enforcing Management Collaboration within and of Teams.
More IT leaders are orchestrating the Agile transformation, senior management and project management needs to work more closely in order to improve overall Agile project success rate. On one side, buy-in from senior management for adopting agile is one of the most important steps in Agile project success, but giving them only Agile specific data is not going to provide a holistic picture. How would CIO or other senior IT leaders like to get update from Agile team, and on the other side, how shall Agile teams forecast for senior management and what is it Sr. Management is looking for that you are not giving them? How do you forecast the end date of projects when the product backlog is huge?
Performed a high level estimation: You may need some visioning and road mapping exercises to get a clearer picture of what needs to be done. You may also want to plan at an Epic level and not the user story level. Long range planning at the story level is too detailed. Build a roadmap of high-level epics which forecasts what features you plan to complete over a general timeline. The forecast will have degrading levels of accuracy the farther out the roadmap goes. This is because the teams will mature (hopefully improving velocity), you will learn things (good and bad), and the customer/business can change their minds about what's important. You always commit to the high business value in Agile and no to the "Epics"
Share with the top management on the release dates. Usually Sr. Management wants the answer to two key questions: 1) When will it be done? 2) How much will it cost? Some agile teams create a share-point based project portal where the progress was updated on a regular basis and open for the project stakeholders to view the progress. Unless all backlog items are required - fixed scope - you can tell them that you will release on exactly the date they need. If your team is fixed and you don't have too much variable cost (overtime), you can tell them exactly what it will cost. What you can't tell them is exactly what scope will be complete - that's what you estimate and you need an estimated backlog and your velocity to tell that.
Identify backlogs, prioritize it: One way in addressing this is, by assigning story points for the high ranked/prioritized stories in the backlog, use the high level effort (Design + Dev+ QA) as the points and then determine the number of iterations it will take to complete from Velocity. Then divide the total story points by the average velocity to get an idea about the completion. Every story point in Agile can be considered as the EBV (Earned Business Value). Since you have annual releases you can say you hope to deliver "n"
Continuously monitored the progress and updated the release plan in terms of features/ dates. Some Agile teams take the total complexity points in the backlog and have a target date. As you finish each iteration, you can perhaps more easily calculate how many story points per sprint to reach the end goal. Your estimate will be a guess, but what you will find is that as your team finds a rhythm, your "Cone of Uncertainty" will
Some Agile teams use a burn-up chart to track the progress, which also shows the amount of new features being added during the release and negotiate with mgmt/product teams in terms of delivery dates and features added/removed. Take the initiative to have a monthly update on this to get their buy in. Some important update include: 1) Reduce scope 2) Drop some features. 3). Consider "Feature Buffer". 4). Look at shared resources
Agile focuses on three Is: Iteration, Interaction and Improvement, senior management and project management need to work more interactively, from planning, forecasting, to measuring and governance, to manage projects via truly adopting Agile principles