Estimating Time on Tasks [closed]

Question

We have just started doing scrum at my company. We are spending a bit of time estimating Effort using planning poker and then when the detailed tasks are worked out a time estimate is put on each task.

The problem we have is that the time estimates are constantly wrong (usually over estimated). Although we can all agree on an effort, getting a team to agree on time for a task is much harder - what takes 1 person an hour might take someone else 3 hours. We end up going somewhere in the middle.

Who should be coming up with the time estimate for a task and when does this happen?

Is this just something we need more practice at, or are we doing it wrong?

Latrena

So many developers do not understand Agile adequately that they thought this was an "opinion" question and closed it. In reality, it is a clear and concise process with well defined mechanisms for planning and executing work. If you think Agile is an opinion, you're not practicing it. – Fatima

Answer 1

The people actually doing the work estimate the cost involved. If you are using raw time as a metric for estimation, Agile methodologies frown on it. Your team should be using an abstraction to estimate cost, such as 'points'. You can start with a rough baseline of 1 hour per point with a minimum of 1 point. Then developers can make raw estimates of how long something should take. Slap them or anyone else on the wrist if they talk in hours or in any other unit of time.

The point is that as development moves along through multiple sprints, project managers can adjust 'point' time estimates provided by the team to match reality -- This can even be done per individual developer. Participants will become better and better at estimation as projects progress. So, since Sprints are an iterative process, time estimates improve with more iterations.

This begs another question: Why are you worried about time? Time is basically cost in the Waterfall model. In Agile, the goal is developing software to VALUE not cost. The reason points are used is that it is an abstract basis of comparison that business owners, project managers and creators (developers) can all view in an abstract light. (Unbiased from different participants' cultural, social or psychological perceptions of time.) Business owners can take a look at available points in a given sprint -- and knowing the points available -- they can elect functionality that is most important. It is always a bit of a tough decision, but again, the goal is to develop toward value and away from time boxing or feature stuffing.

Fatima

Thanks for the answer. We're using the TFS agile template and it has Effort on a PBI/Bug, but the individual tasks have time. All of the burn down happens from the time. Is this just a short coming of the Microsoft model? If we don't set time we don't get a burn down to tell us how we're going – Latrena

As ingyhere said, you shouldn't use raw time for your estimation - or better: you cannot use time as a cost value in Scrum. Solution for your porblem: Stick to the points for the storys, but DONT estimate the single storytasks. If you want to create your burndown, count the tasks and divide the story points with the task count - e.g., Story is 8 points, you have 4 tasks, so each task has a value of 2 points. If you solve 2 tasks during the day your burndown will go down 4 points. – Salientian

As you pointed out, the time used for a task depends on the person which works on it. But the idea of the story points is to not depend on the people. The Team is in focus. So the points reflect how much effort to team needs to fulfill this story. Just do the same with the tasks. If you want to estimate the effort of each task individually, just use story point. The sum should then round up to the story points of the according story. – Spousal

Answer 2

"Who should be coming up with the time estimate for a task and when does this happen?" Depends on how you run your team. Do you let the team members truly self-manage, so tasks are assigned when a person grabs it during the sprint? You may have to keep using the time to complete based on the abilities of an average developer on the team. Do you have a team lead that assigns the tasks to people as they are created during the Sprint Planning meeting? Let the person assigned estimate the time to complete the task.

I agree removing time from the effort estimate is a bit confusing. The big question is: what does it matter that you are overestimating the task time? Is the team sitting around for 4-5 days at the end of a sprint with nothing to do? If so, go to the Product Owner and let her know the team wants to add one or two small items into the Sprint. You don't normally add stuff to an ongoing sprint, but Scrum is a framework to manage work, and as long as the team signs off on adding the new items, there is no need not to let Scrum work for your team....not force your team to work for Scrum.

Also, your questions seems to indicate your team has a greater velocity than what is being planned. If your 2-week sprint (10 work days) has a velocity of 10, but your team is getting finished with everything by day 7, just up your story points on the next sprint to 11 or 12.

Stelu

Would like to know why my answer was down voted. – Stelu

My thoughts are the answer is talking explicitly about time as a concrete estimate when Agile is trying to abstract it. (Everyone has their own clock which is why points are used to avoid missed estimates.) Also, Agile is not a framework for heavy-handed assignments by a team lead. That would indicate that the methodology is not being applied well. – Fatima