### 7.3.1 Development Status Report The Development Status Report documents and communicates the **status of the Agile Project Core Team (A- PCT) towards the development goals** and it’s incorporated at the project reporting level. Similar to the Project Status Report, the Development Status Report includes tracking information regarding the **cost, schedule, scope, risks, issues, changes, and forecasts for the project’s next steps**. The Development Status Report can ==follow each iteration and/or each release, depending on the reporting needs defined for the project==. One of the key elements of the report is the **burn-down chart**, both at the iteration and release level. The **release burn-down chart shows the estimated functionality remaining to complete the current release** and It provides answers to the following questions: - When can a release be completed based on the team’s performance (velocity)? - What progress has been accomplished so far? - Is the team’s velocity sufficient to complete the release on time? The **release burn-down chart** provides a broad view of a release’s progress. It is reviewed, at least, once each iteration, and indicates if the team is delivering functionality at the expected pace. It can also expose projects whose scope is out of control and thus, negatively affecting the expected progress. Based on a trend or forecast, the chart allows the team can take action to better control scope, or adjust resources, budget, timelines, quality levels or commitments. The **iteration burn-down chart** is the primary tool for understanding the status of the current iteration. It shows the current team’s performance, based on estimated effort left versus the optimal team’s performance, based on the expected effort left that guarantees the iteration goal’s fulfilment. The iteration burn-down chart should be **updated frequently, preferably daily**. Daily or frequent updates allow the team to react to changes. For example, changes can include reducing the project scope by removing Work Items from the iteration or the Work Items List, reducing the ambition level associated with a work item, or finding better ways of approaching Work Items. Unlike the iteration burn-down chart that tracks remaining effort in points or hours, the release burn-down chart tracks functionality to determine whether the team is delivering working software in each iteration. The resulting release burn-down chart helps comparing how much functionality the team is delivering with how much they forecasted to deliver. | Key Participants | Description | | :---------------- | :----------- | |Team Coordinator (TeCo)|Responsible for preparing the Development Status Report and ensuring the alignment of the development-related progress information<br> with the project-level Project Status Report, in close collaboration with the Project Manager (PM).| |Agile Team Member (ATeM)|Supports the preparation of the Development Status Report by providing information on the work they perform daily.| |[[Project Manager (PM)]]|Accountable for the Development Status Report, the Project Manager (PM) must be aware on how the Agile Project Core Team (A-PCT) is progressing.<br> She also ensures that the Project Status Report's relevant information is captured from the Development Status Report.| |Product Owner (PrOw)| Is informed about the progress of the team.| **Guidelines** - **Refer to Development Work Plan** – The Iteration and Release Plans provide critical and transparent data for a precise and objective Development Status Report. Team’s velocity, burn-down charts, Work Items List and an updated Release strategy are some of the elements available. - **Project Management Logs are also vital** – Issues, decisions, risks are all part of a project’s day-to-day life and must be managed closely. Keeping the project management logs current ensures everything is addressed and resolved. - **Align Progress meetings with Iteration and release cycles** – Because every iteration provides objective information on the Agile Project Core Team’ (A-PCT) actual progress, having a progress status meeting at the end of each iteration is an effective way to communicate the development effort’s status. - **Transparency** – Always keep the status information visible to stakeholders and the project team in a project workspace (==walls or automated tool==), where stakeholders can come and experience first-hand the progress being made by the team. ![[7.3.1 Development Status Report — Inputs and main roles - 1.png]] ![[7.3.1 Development Status Report — Inputs and main roles - 2.png]]