How to visualize Agile projects

Agile is about "team overall" experience. We plan together, encode together, test together, examine the past together so that everyone on the team can agree on a consensus. However, as the project grows, the team begins to get lost in the pile of user stories, making it difficult for everyone to see the same panorama (big picture). This paper discusses various methods of visualizing panoramic images. Not only for principals and managers, but also for everyone.

Ideally, the agile team should propose a clear plan for the current iteration, and the subsequent release plans could be sketchy. In fact, in many cases, the team is just rushing to achieve the next little idea in the current iteration. They completely ignored the panoramic view. There is usually a situation where this image is stored in the head of a persona, such as team leaders, business analysts, project managers, product managers, and even scrummaster. This is often caused by the fact that he or she did not really push the self organization. This phenomenon is acceptable in some cases, such as an unimportant short-term project, but in many cases it can have bad consequences, and when the team deviates from the track, they are not aware of anything because they feel that all the work is still working properly.

Business value

In many cases, we plan things on the basis of some great ideas (which may come from company founders, department heads, customer groups, or communities). In our real world, these ideas are usually not static, and it is constantly changing. If you can pinpoint the progress of the project Panorama (big picture), we can have more insight to help us maintain the right direction of operation.

For example: Your big Boss insight to login via LinkedIn would be a killer feature, it is very helpful to penetrate into the untapped professional market, but once communicated to the Product manager there is a distortion of information communication under the influence of various reasons and the priority is not properly understood. The APIs used to connect are not readily available. There are 5 other issues in your production environment, and many other legitimate reasons that have caused you to not schedule this new feature. In the end, there is less than half the time to release, and you haven't even started developing this integration feature. It's best to let your boss and team know the difference from the beginning, not to the end.

Sometimes the team is obsessed with the technical issues of secondary characteristics, where the investment is too high and the return on business value is low. Assuming that the team has spent half in the first 3 iterations in an effort to address integration with Foursquare, the product manager who understands this will decide to say "forget it" and move on.

So how do we make this information visible?

Burndown chart (Burndown Chart)

The Product Burndown chart is the Agile Team Classic Progress visualization tool, it is very effective to depict the team progress speed and the production capacity. It can be based on hundreds of story points and the state of the detailed presentation of the outline. It has its own unique beauty, but only these may not be enough. Suppose you have reached your goal on time, but you find it a wrong goal! Burndown chart can determine the completion of the time, but can not determine the completed content. The following fictional Burndown (Agile estimates and planning from Mike Cohn) shows a few additions to the end of iteration 2, and everything is back on track.