Showing Daily Progress

## Introduction

Controlling and monitoring of progress in projects is very key in agile project management. While traditional project management is more concerned about observing and measuring the performance of the project against the plan, agile project management offers more opportunities to monitor and report on the progress of a project. As such, there are more opportunities to intervene and control the project itself. Stakeholders in a project generally deserve to see what is going on with the project they are paying for and on which they rely to add value to their businesses. It is therefore important for project managers to continuously keep their stakeholders informed of the progress status of their projects.

Agile reporting has, therefore, become widely adopted in project management as it offers project team, sponsors, and customers a number of benefits. Daily progress reporting is important since it allows for more rapid deployment of solutions in case there are any errors in the project or changes to be made. In addition, daily reporting enables the project manager to reduce waste by
minimizing the unnecessary resources being used (Sutherland, et al, 2007). It also allows increased flexibility and adaptability to change by the organization and project leaders.  By reporting the progress on a daily basis, one is able to detect issues and defects in the project faster and fix them promptly. It also allows for increased frequency of collaboration and giving of feedback by the various stakeholders. Finally, daily progress reporting also enables optimal project control and increases focus on the specific needs of a particular customer.

There are a number of different reporting techniques for different projects that keep the team and the customer and the team informed on the progress of the project on a daily basis. There are several tools for communicating the status and progress of a project.  This paper uses Scrum as an example to define the reporting expectations (Schwaber, 2004). In Scrum, there are typically four reports created at the end of each iteration. Firstly, the product backlog is used as a repository for the entire project. It is simply a list of all the items and things that are needed to be done in a project. Entries to this report are made on a daily basis and updated based on the changing needs of the project. Different agile teams keep these reports differently, either in excel, a whiteboard or even on sticky notes. This makes it easy to move around change and reprioritize accordingly.

The second way is through a sprint backlog. When updated on a daily basis, it gives an up-to-date status report to all the project stakeholders. Ideally, the sprint backlog is a subset of the product backlog with a narrow focus on the features in the most current iteration. The stories to be developed in every sprint are selected by the team and updated regularly to reflect the reality of the progress of a team. The third way is through a changes report (Cervone, 2011). Due to the complex nature of some projects, teams may misjudge their ability to deliver or the complex features of the project. The changes report helps teams and stakeholders to add, delete or modify feature while the project is in progress. The report also enables one to keep track of the changes on a daily basis and allow the product owner to approve various changes. Finally, a burndown chart can be used to quickly show the status of a project.  It can show whether the sprint is going according to plan or not.  In this manner, the burndown chart is said to give an up to date progress to the project developers.

## Work Cited

Schwaber, K. (2004). *Agile project management with Scrum*. Microsoft press.

Cervone, H. F. (2011). Understanding agile project management methods using Scrum. *OCLC Systems & Services: International digital library perspectives*, *27*(1), 18-22.

Sutherland, J., Viktorov, A., Blount, J., & Puntikov, N. (2007, January). Distributed Scrum:         Agile project management with outsourced development teams. In *System Sciences, 2007. HICSS 2007. 40th Annual Hawaii International Conference on* (pp. 274a-274a). IEEE.