In the previous article, I first talked about 1) the first step of agile - daily stand-ups, then talked about how to 2) use Kanban to manage projects or manage your own work to-do, and today is the third topic, how to do task breakdown, estimation and work assignment in real projects. Agile development
Task dismantling and evaluation is a very detailed and experienced task, usually the team leader is usually responsible for dismantling, evaluating man-days and assigning personnel.
Some people say you're fake agile.You're right. However, in practice, we usually decide whether to adopt it based on its actual effect. Theories or doctrines can guide practice, but they cannot replace practice. Only theories that have been proven in practice are the most convincing. The reason why we evaluate the work here and assign the work by the team leader is that the leader has a better understanding of the overall architecture, module division, and implementation details of the entire project, so it is more reasonable for him to disassemble it.The workload should be evaluated by itself, and the leader is not required
The workload should be based on story points, not man-days;
Tasks should be claimed by oneself and do not need to be assigned.
The leader understands everyone's strength level and work efficiency, and already knows which student is more suitable to complete this work. After combining the two factors of story points and executives, it is easier to understand and follow up on the evaluation of time and workload.
The leader is responsible for moving the project as a whole quickly, and needs to be able to assign team members to get work done quickly, which is very efficient.
After practice, we found that there is no problem at all in doing so.
There are two important principles for our task disassembly: 1) the principle of value priority, and 2) the granularity should not exceed 3 person-days.
Priority dismantling of value tasks: When disassembling a task, the task of **value is disassembled first. The value of your team and product can only be maximized by always prioritizing the functions and features that are most valuable to the end user and the product.
The granularity of the task should not exceed 3 man-days, that is, if a task needs to be completed within 3 days. Not doing it in three days is a very serious thing. If the split is unreasonable, it should need to be fed back on the first day;If you have a problem, you shouldn't bring it up on the third day, after all, we stand up every day. In fact, the most fearful thing in the work is that there is no feedback in advance, no progress in the process, and then the deadline cannot be delivered.
We expect to be able to maintain small-grained tasks and make progress every day, rather than a huge task assignment that will not progress for half a month, which will lead to team members having no awareness of the task, the project will largely get out of control, and the final delivery date will have a frightening ending.
This article focuses on some of our practices in agile development practices, including team leaders breaking down tasks, assessing workload, and assigning people to complete tasks, which we believe is the most efficient and least risky for the whole teamFor task disassembly, we mainly have two major principles: the principle of value priority and the granularity should not exceed 3 person-days. Doing so helps us stay focused on the functionality and features that are most valuable to our users and products.