Release Forecasting and Tracking in Agile

Transcription

1 Release Forecasting and Tracking in Agile Author: Abhirup Roy

2 Release Forecasting and Tracking in Agile If you are a Product Owner then it s quite likely that you have a real tough time forecasting the feature delivery schedule to stakeholders. In other words how much can you deliver in a given time frame. The situation becomes even more dismal when the priority of items in the backlog and/or the scope keeps changing. How to solve this problem? If you are like many other Product Owners, you maintain a spreadsheet where you manually enter all your data and plot a Release Burndown graph. But there are some major limitations with that: ABHIRUP ROY PRODUCT OWNER First and foremost it is a tedious job; you will have to create the complete data set in spread sheet. The same time can be better spent in analyzing business requirements. On change of priorities or requirements, rearrangement takes up a lot more time yet again. You don t get a realistic and real time release forecast in the excel sheet. It is unclear how the release date will be affected if some items are added or removed from the release plan. You cannot adapt the release forecast based on changes in the team s capacity or some other unforeseen business issues. It is difficult to track your optimistic and pessimistic release dates based on actual team velocity statistical data. It is difficult so see/know if there are some items in the Release Backlog which have not been estimated yet. To find these items you would need to go through them one by one. There is no easy way to track the release based on sprints and months and hence take remedial actions. The spreadsheet is not visible and accessible to all stakeholders, at all times. To make release forecasting and tracking easier a release planning tool is a necessity, but unfortunately there are no such tool available which will make our lives easier. To answer this problem, Agile Cockpit created a release planning tool in the backlog management feature. With this new feature: Abhirup is a Product Owner for Agile Cockpit and has over 10 years of experience in Product Management and Process Engineering. As an Agile enthusiast he takes keen interest in helping improve processes and functioning in teams and believes in the power of vision, passion and communication in solving real life problems and creating successful market ready solutions. It is easy to create a release plan by adding prioritized stories from the Product Backlog to the Release Backlog. You can easily see your release forecast the expected release date. It is easy to make necessary changes to meet release date deadline. You can continuously monitor and track the release progress. You can adapt the release plan to changing business needs and easily take remedial actions based on actual release progress. 2

3 How to use the Release Burndown First Create a Release by selecting the + icon in the Release Column. Mention Release Start Date and Release End Date; the Release End Date should be either equal to, or less than the market release date. Ensure that the prioritized stories in the Product Backlog are estimated in story points Now you can simply drag and drop prioritized stories from the Product Backlog to the Release Backlog. As you keep adding Backlog Items to your Release Backlog the Release Forecast will be created next to the Release Backlog and will show you the: (a) Total Story Points added to the release (b) The release end date (as defined by the user) (c) The expected release date (calculated based on the Avg velocity/day in the past 6 sprints) (d) The pessimistic release date (calculated based on the least Avg velocity/day in the past 6 sprints) (e) The optimistic release date (calculated based on the highest Avg velocity/ day in the past 6 sprints) (f) The number of unestimated stories in the Release Backlog 3

4 How is the Release Burndown calculated? For calculating the expected release date the average velocity per day is considered for the previous 6 sprints. A minimum of 3 sprints data should be available. If at least 3 sprints are not available a default velocity of 1 is considered. This default velocity can also be changed to a custom value by the user. The minimum average velocity/day and the maximum average velocity/ day are considered for predicting the pessimistic and optimistic release dates. If you (as a Product Owner) think that the average velocity/day of the team should be different for the release you can enter your own custom velocity/day. Based on this the release trend lines will be drawn and new expected, optimistic, and pessimistic release dates will be plotted. While predicting the pessimistic and optimistic release dates the actual variance is considered from minimum past 3 sprints data or maximum past 6 sprint s data. Later on as the release progresses over sprints/months you will get a realistic release expected date forecast based on remaining scope of work and entered custom velocity. If you want to use the actual velocity of the team you can do that any point of time by selecting the reset button next to the Custom Average Velocity/day. 4

5 As the release progresses in sprints/months, the updated data will be displayed. After each sprint you will know whether the release is going well or if it is running behind schedule. With the updated data remedial actions can be taken to meet the release date. This new release planning feature should help Product Owners, stakeholders, and teams to plan and track their release efforts and help align business goals and development efforts better and above all, much easier! 5