Iterative planning for TFS Kanban

Story Point

The story point is more about the user story or the size of the bug, using a number representation of the Fibonacci sequence (1,2,3,5,8,13), including the following:

1. Relative workload
2. Complexity of
3. Risks and uncertainties

Relative workload

The following shows a case to illustrate:
Suppose there is an edit page A with 10 fields and B has 100 fields:

The relative workload of B should be larger but not 10 times times absolute. Maybe 3-5 times. The reaction is the story point increase

If you consider the existing dynamic form generation, then A and b two cases should be the same complexity, the response is the same story point.

Complexity of

For the above 100 fields this case, if there are some data binding in the field, complex control and so on, then inevitably bring the complexity of the rise, the reaction is also the story point increase.

Risks and uncertainties

For new technical research and analysis, such as the first to investigate a third-party API. A technical implementation feasibility analysis can be converted into a workload.

Attention

1. The development should be able to adjust the story points considering the different workload estimation differences brought by different implementation ideas.
2. As far as distance is concerned, the estimation of absolute distance is often not accurate in relative distance.
3. The story point only makes a relatively approximate estimate, does not require very precise, but must be persuasive.

Speed chart

Speed chart in the top right corner of the to-do list, over time, the speed should be displayed as a reliable number that can be used to predict the average completion story point. In order to realize the efficiency of the speed graph, the following requirements need to be met:

1. Plan your iterations according to your team (don't plan at the top-level team)
2. Define iterations for the team (the iteration should be as long as possible)
3. Choose an iteration plan for each team (you should allocate as many as 2-3 iterations)
4. Need to be as independent as possible, not too much relevance (need not nesting requirements)
5. After the iteration is finished, update the backlog to close if it is not closed, and then re-plan

6. Complex bugs need to evaluate story points and task splits (complexity requires development of their own evaluation)

   Because the default in an iteration is to fix the bug in the iteration at a certain time, if the time is enough to fix the historical bug, some of the complex bugs take a long time and are recommended as a requirement to estimate

Speed prediction

Turn on the prediction tool by opening the trend forecast in the scenario-by-agent list (it is recommended to hide the in-progress items).
You can use the Prediction function by setting the speed forecast value reasonably according to the speed chart.

Precautions

1. Require story points to be set for each user story and bug
2. You can sort the user stories and tasks to re-predict
3. The prediction of velocity is just a relative value not an absolute estimate (this part refers to iterative capacity planning)

Role

1. To plan the future progress of the project in general
2. Plan (sort and prioritize) your work
3. Resources for a reasonable allocation team for forecasting

Capacity Planning

Based on the iterative speed prediction is a general judgment, capacity planning can help us do accurate calculations. But capacity planning, based on the team's situation can actually be adjusted, should not advance too much, this part can be determined by the team at the beginning of the iteration at the planning meeting.
Configuration steps:

1. Select an iteration to open the Capacity tab
2. Select team members (can include products, development, testing, etc.)
3. Configure the amount of work per day (note that different activities can be configured).
4. Configure Team rest day (weekend default rest, can be the development of the board after the day as a rest day)
5. You can usually copy the plan of the last iteration and modify it as needed.

The capacity of the team appears on the right

Task splitting

With capacity planning, after the rough planning of the iterations, we need to plan what to do in detail, and the specific work of the iteration is based on the task, using the story points to make a rough prediction, using the remaining work of the task to do a detailed division, for the following reasons:

1. The story point is just a relative concept, more vague
2. The process of demand splitting can be designed for a requirement or bug.
3. The splitting of requirements includes the design process to prevent the defects of the requirements in advance.
4. Task more detailed and convenient to make more accurate estimates
5. Task initial estimate and remaining work are created equal
6. Task initial estimate and remaining work in hours units

Requirements or bug splitting tasks need to fill in the initial estimate and title, you can fill in the detailed content as required. The default is who needs who to split, who splits the task is assigned to whom. Precautions:

1. Requirements should be removed by testing a use case design task, activity for use case design
2. Complex bugs should split tasks. Activity for bug fixes

After the split above, on the right side, you can display both the overall time of each person and the time it takes to complete the task within the iteration. Appropriate reduction of requirements based on the results of the final split.

Burndown Chart

When an iteration is selected, the upper-right corner of the graph is the Burndown chart.
Available capacity lines (highest point iteration begins with the maximum working time available, lowest 0)
Ideal Trend (maximum value of remaining work at highest point, lowest 0)
Remaining Work (line chart for remaining work per day)

Use the following resources to learn the Burndown chart:

1. Https://docs.microsoft.com/zh-cn/vsts/work/scrum/sprint-burndown
2. http://www.methodsandtools.com/archive/scrumburndown.php

Iterative planning for TFS Kanban