Agile development routine follow-up series 4: Follow-up table

This is the fourth article in the daily follow-up series of agile development. (Topic directory)

Follow-up tables are a practice of large agile teams. In an online game team of more than 80 people, they used this method to clearly show how the entire team works.

Follow-up table

The preceding online game team is used as an example to describe the following information:

1. What stories have been completed

It can also be expressed in the story board, but it lacks structure. The stories on the story board are all equal, making it difficult to show the size and parent-child relations.

2. who is following up

In this case, this person is generally a planner, the creator of the story, and the reviewer.

3. WHO is developing

In this case, this is generally a group of developers, scripts, and art, and may only have one type of work.

4. When or when a task may start or end.

It cannot be expressed on the story board or burned-out diagram.

5. What stories have been shelved

There may be difficulties, other reasons, or even half done.

......

Instance

This is an iterative follow-up table case that has been completed in R & D of "Martian.

Instance 1

Let's take a look at the iteration's burn-out diagram (right-click the picture to save it and watch it ):

For the 5 Functions of following-up graphs, the extended burned-out diagram can only be the first one, that is, "What stories have been completed", and the general burned-out diagram does not even play this role.

The following follow-up table is required to achieve the other four goals.

First, let's look at the blue box on the left, which contains all the iterations (sprint backlog). Why is this tree structure displayed? Because for a small team, only 10 ~ Even if there are 20 stories, people can remember and understand what they mean from a story name with only three words, such as a new interface. However, if there are too many stories, it will be difficult, and the name of the story will have to be long. For example, "the plan will-the new interface for explaining the story", and such expressions seem okay, however, because there is no clear parent-child inclusion relationship, it is also messy. Therefore, the Blue Circle is expressed in the form of parent-child relationship, which makes R & D of large products clearer.

The two columns on the right of the blue box are the person in charge (corresponding to the person in charge, the person in charge in the case) and the current person in charge (developer). Because our team is small and there are no two departments, no follow-up person is set, therefore, there is no "owner ".

The base colors of the tables in the three yellow boxes are green, pink, green, and pink, respectively. The vertical box on the left indicates that everyone worked overtime on the 15th day. The reason is that on the vertical box on the right, everyone went out for a spring outing on the 19th day. The horizontal yellow box indicates that yock had a lot of vacations this month, he can only finish his work on a specific date. Why do we need to manage this? Sometimes it seems that the burn-out chart points to 0 points, but that place may be just like Spring Festival, May Day, or new year's day. With the overall grasp of the holiday, the risk of important online activities is reduced.

The story in the red box looks a little abnormal, because although the entire iteration is over, its remaining time is still "1 person-day", so the story is not complete, and it stops on the 17th day.

Instance 2

The figure below shows how to adjust some data and adjust the system time to 2.26 to simulate an ongoing iteration.

On the rightmost side, we can see that four stories have not been completed. Two of them are not yet started (the top and bottom are light-colored), and the other two are encountering obstacles, no progress will be made after the day 17 and 24.

As a project manager and Technical Manager, when you see the story of obstacles in the follow-up table, you must promptly ask and coordinate the story. As a programmer, you should also report the stuck story at every Hitachi conference.

The silent programmers and blind project managers (the project managers of larger teams are more serious) are the important reasons for large-scale project failure.