Agile is about overall team experience

Summary: Agile is related to the overall team 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 starts to get lost in the huge pile of

Agile is about the whole team 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 panorama. 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 they are 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 describe the team progress speed and 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 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.

How do we visualize the panorama? Here are a few tips.

Epic Story (Epic)

Epic stories are fundamentally just big user stories. Thanks to Mike Cohn and his book Agile Estimates and planning, the term has been widely used. However, epic stories and similar terms (such as themes and features) have different applications in different agile teams, but they are a technique for grouping user stories in either team. In a comment in his own blog, Mike Cohn mentioned that it was originally Kent Beck who explained the term to the epic story. Here are some definitions from this blog:

1. When we call a particular story an epic story, there is no special boundary. It means just "big user Stories".

2, "Theme" is a series of user stories. We can divide the story of the monthly report into one group and take a rubber band to bundle them up and call them "themes".

It also means that the epic story has nothing to do with the subject. The following picture will help you to understand better.

Mike makes an interesting summary, "to call a story an epic story can sometimes convey extra meaning". For example, the story is expected to be large and we need to break it down into smaller stories.

Lean people also introduced other terms such as MMF (minimum market feature or minimum market feature set minimal marketable Feature or minimal marketable Feature set) This is another way to define requirements. MMF is usually bigger than the story, so many people have seen it as an epic story, but it has more specific definitions than the big story. If you post something that customers buy, the feature is less and the customer does not buy, so the minimal feature set is MMF. If it doesn't have a market, it's probably too small, and it can't break down a bigger story. One or more MMF is published with the smallest available product (MVP). Because of the emergence of Lean Enterprise (Lean Startup), the term has been very popular recently.

So we have epic stories, themes, and MMF. What do we do now? How do we use them to help us get a better panoramic view?

Story map (Story Mapping)

The story-mapping model, which is popular with Jeff Patton, is a visual way to deal with a lot of stories (backlog). According to Mike Cohn's description of the epic story, the story map is just a map of an epic story, all of which are on a big wall. The backbone (backbone) contains an ordered list of epic stories, and when you list a child story, what stories do you think you want to tell, like the skeleton Man (walking skeleton), which takes precedence in the trunk (Edit note: Start walking in a state where the skeleton has no meat). The following figure is from the new user story The to-do list is a map (the new username story backlog is a map), written by Jeff Patton in 2008.

As follows, Jeff describes the use of the story map.

When this project is running, it becomes a publicity board for our sprint or iteration plan. We identify or divide the story directly on the schematic diagram to be built in the next iteration. We will not just place stories during iterations, we use the task wall to manage their development--but this story sketch on the wall of the plan reminds us of what a panorama is and how much progress we've made.

Story mapping is really a great way to organize a lot of work to do. It is better to tell a story than to describe the job in a straightforward manner. Grouping stories in the same backbone projects (such as epic stories) helps us communicate at a higher level, and the effect is better than communicating in a detailed story. It is also very helpful in selecting the smallest available product components, and you may need to build a minimum available product from one (top) point stack of each skeleton person.

However, sometimes you just need a separate picture to depict the project outline. You've shown the boss a Burndown chart, but it expresses "when" instead of "what." You want your boss to spend some time on the big story map wall, but it's hard to get it. What are we going to do?

Parking lot Map (Parking Lot Diagram)

Written by Mike Griffiths in 2009, "re-discuss the parking lot map--use the area to show achievement (Parking

Lot diagrams revisited–using area to show Effort) mentions an interesting panorama visualization technology-"relative size" parking lot.

The traffic light color represents a sense of urgency, such as red means that it has missed progress, and green means it can meet the deadline requirements. Because most projects are still in the process of moving towards deadlines, they are always expressed in yellow. Relative size is an improved version of the original size parking diagram. The larger rectangle indicates that it has a larger value (in the story point). The authors point out that the figure is easy to understand, but it is difficult to draw in PowerPoint by hand. The blog also mentions some other ideas, including a simple scaled histogram, which is easier to use in Excel drawing or coding implementations.

Tree Graph (TREEMAP)

Another visualization is to visualize the backlog of large products through a tree graph (also called a thermal map (heatmap)). This was written by Mike Cohn in 2008, and I thought it would make sense to record large and complex datasets. Although written a few years ago, Mike Mike still insists in recent comments that it has been the best way to show large projects.

"Yes, I still think it's the best way to visualize large products being done." The tree chart has withstood the test of time, such as the graphical stock market, so it is still a good technology for us in the recent period, and I don't want them to be replaced [Mike cohn,2012 May 11]. ”

The following tree is from the recent to-do list in the Eidos beta, which was drawn through the Google Chart Tools API, and my company is working on this Agile Project Synergy tool. The dark green blocks indicate that the next epic story has made some progress, and that their area is proportional to the size of the epic story (the sum of the story points of all the stories). This tree chart tells us that because many of the big epic stories have been completed, the beta version of Eidos is nearly ready.

These pictures provide us with a nice snapshot of today, but it doesn't tell us anything about the past or the future, because there are only two dimensions of data, for example, in this case, only the size and state of the epic story, but there is no time dimension.

Dart Target (dartboard)

The following Dart target, presented by Nicholas Muldoon in the epic visualization of the product, is a graphical "plan" for each epic story represented by each area. Each block symbol is a story. The inner circle is the current version, and the 4 circles on its periphery are the next 4 versions. The symbol outside the circle is the unplanned story. The traffic light color represents the extent to which the story has been completed, from red to yellow to final green.

Although the graph shows the time dimension, it does not really show the relative effort required between stories. Perhaps, by the size of each symbol to reflect its relative size, it can easily be further enhanced.

Area Stacking chart (stacked areas Chart)

In Eidos, we are studying how to visually visualize the panorama. Another method is an area stacked graph. This figure shows not only the relative size and status, but also the time that progress has been experienced. For example, for the epic story on the storyboard (Storyboard) and the story Card (Storycard), you can see all the work we've done from the start to the present, and the iteration plans and attachments we just submitted in iteration 6.

Enhanced Burndown chart with epic story bars

Another way is to display epic story progress under Burndown charts, the original Eidos screenshot below. In the bar chart below the Burndown chart, each color block represents the total number of story points for each epic story. In other diagrams, an enhanced Burndown chart can also show each epic story "What Remains" is not implemented.

Summary

All of these visualizations are trying to solve the same problems, such as summarizing large, complex datasets in different dimensions such as time, scale, and requirement groups. More complex data and visualization, you need to be more automated to express the panorama.

Let's review all the visualizations that have been discussed. The key difference is in the dimensions and what you intend to visualize. Obviously, if you use a screenshot that shows only a point in time, such as a tree, you can't display the data for each time period.