Project Kanban (Physical Kanban and Electronic Kanban)

Kanban allows everyone to understand what the team is doing and planning to do in a delivery cycle, and who is the executor of each task at each stage. Kanban has high transparency of information and status.

The roles of team members are different, and they have different perspectives to look at problems. Especially in distributed teams, it is unrealistic to transmit information to everyone accurately through traditional means. Using a physical or electronic Kanban to transfer information is both accurate and fast, and it can prevent information from being missed. Kanban, as a simple and intuitive existence, unifies everyone’s knowledge and instructs the team to work towards a common goal.

In a distributed team, we can only learn about the progress of other teams through the electronic Kanban. This is especially meaningful for distributed teams with high interdependence. We will pay attention to whether other teams arrange the story cards we rely on into their iterations, and the status of these story cards in the remote team iterations. We can use this information to estimate when the story cards will be delivered and how much workload can be delivered in this iteration.

Generally speaking. Kanban mainly has the purpose of continuously improving the work of the team, showing the team’s work process, limiting the quantity of Work in Process (WIP), shortening the cycle of story cards from planning to delivery, and so on.

Burndown Chart

The burndown chart reveals the trend of the project’s entire delivery cycle and can support the prediction of the project’s completion date. It graphically shows the relationship between remaining workload (vertical axis) and time (horizontal axis). Ideally, the graph would be a downward curve, and as the remaining workload decreases, “burn” to zero. The burndown chart usually appears in the iteration report, which can be used as a public view to provide project team members and customers with work progress.

The burndown chart is very helpful to the team because it focuses on the remaining workload. As the iteration progresses, the trend it forms provides a basis for predicting the end time of the project and helps us track the project progress.

For customers, the burndown chart is also highly valued. In addition to tracking the project progress, they can learn about the team’s development speed from the burndown chart. However, to ensure the accuracy of the data for the development speed, the way of the team to respond to changes in requirements during iterations is to ensure that the backlog could remain constant with the total workload delivered for each iteration plan. For example, if a customer temporarily adds a new requirement, if it cannot be scheduled to the next iteration cycle, it is necessary to remove a task of equal workload from this iteration, together with the same workload with the lowest priority from the backlog.

For distributed teams that adopt agile development practice, each team can draw its own burndown chart independently. Although the standard for estimating the workload of each team is not consistent, but after the workload is divided by the team’s delivery speed, the calculated date is relatively accurate. In this way, we can coordinate the common online time from a higher level, and play a strong role in supervising the teams that are behind the development schedule.

Burnup Chart

Whether to use the burndown chart or the burnup chart in the project depends on what the customer and the team want from it. The burndown chart focuses on how much work is left in the project, while the burnup chart tells us how much work has been completed and how much is the current total work. Both of these charts are very common in agile development teams or Scrum.

Compared with the delivery time, customers pay more attention to the content of delivery, then the burnup chart is the best choice. The most important purpose of the burnup chart is to flexibly respond to frequent changes in requirements, and even to adjust the requirements to determine the release date at any time. Therefore, the curve of the burnup chart cannot accurately reflect the development speed of the team.

In general, visualization methods such as burndown chart and burnup chart, although they can also be regarded as data visualization in essence, they cannot be separated from the dimension of time. This dimension (horizontal axis) can reveal the time and location of the problem. We can therefore make better use of these charts, for example, to find some improved methods based on the gap between actual results and expected results, or to make some adjustments to future forecasts.

 
Source
< Prev   CONTENTS   Source   Next >