Following Agile Principle in Enforcing Management Collaboration within and of Teams.
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 resourcesAgile 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
0 comments:
Post a Comment