Answer the question
In order to leave comments, you need to log in
How does Agile get around the fact that the task was priced very ambitiously?
I honestly am not strong in Agile methodologies, I heard about them superficially.
Can you tell me how it goes for you?
1) I am compiling a gantt chart, and, let's say, one task that was estimated at 10 hours - but it turns out that it has a lot of pitfalls, in fact it takes 50 hours and IT IS NOT YET KNOW how much more time is needed. She also pulls a lot of tasks that are not directly related to her. It turns out that I need to move the diagram almost every day, a very large number of subtasks are created in this task, it was possible to take this task out on a separate milestone
2) In the Agile theme, plus or minus this approach, it seems to me:
We get together as a team and take tasks from the backlog and evaluate them. And here is a challenge with new technology, with a new base, which the developers estimated at 10 bunnies, which fits into the sprint of one week. But in fact, one task includes tasks for 4 sprints. How to be here? At the end/during the sprint, is it backlogged again and reevaluated? crushed? can do task-study tasks? but even there it is not always possible to evaluate it
Answer the question
In order to leave comments, you need to log in
1) Evaluation is usually based on previous experience. Tasks with new technology and a new base do not have a sufficient basis for evaluation. It is advisable to create a research task first. The result of this task should be an evaluation. The research task is also not easy to evaluate, but it can be limited. For example: "Give an estimate with the accuracy that can be obtained by spending 16 hours on research." In any case, this will be more accurate than the "offhand" estimate. If the task will be evaluated by 1 person, and not by poker, then use the 3-point assessment for clarification.
2) 50 hours is a little more man/week. Do you have a sprint - less than a week? If, nevertheless, the task goes beyond the boundaries of the sprint, it must be divided into parts (preferably no more than 3-4 people / days) and these new tasks should be distributed over the next sprints in the general order. Another option is to consider whether the same business value can be obtained in a different, less costly way.
3) Scrum uses a burndown chart instead of a gantt. You don’t need to move it, you just need to draw every day. By the way, when using a gantt, you do not need to manually move it if there is a regular status update from developers (for example, in MS Project).
Of course, I may have realized it late, but you will forgive me, I have not read such nonsense in the comments for a long time.
There are 3 basic rules for your question (I'll list them in case anyone else stumbles upon it in the future):
Any task over 20 storypoints must be broken down into subtasks for control and normal execution. Up to 1. Do the first part 2. Do the second part 3. Put it all together
2) 40 hours - man-week? Pfff! Nonsense!
If you think that it is possible to work effectively 40 hours a week (without being distracted, sorry, to go to the toilet or drink water), then you are deeply mistaken. Perhaps the reason lies in this. Statistics and bitter experience tell us that perfect, I repeat, perfectman-day implies 6 hours of involved workflow. So perhaps the problem is just a misunderstanding.
Evaluation Task evaluation is for planning, not for reporting. If you misestimated a task, then at the end of the sprint you re-estimate it not so that your boss gives you a salary for each hour of work, but in order to understand 2 things: 1. You have a problem with task estimates. 2. You form the number of tasks per sprint incorrectly. How to dance further with this information is the choice of each individual manager.
I hope my answer was not too harsh and at least someone else is useful.
All the best! (:
And how did it happen that you misjudged the task? Did you unanimously agree that 10 hours are required (although in fact more than 50)? This means that you have problems with task evaluation: either you have incompetent employees who cannot soberly assess labor costs, or you are constantly distracted from work, or the task is chosen incorrectly. Tasks need to be divided into smaller ones so that they certainly fit into the sprint.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question