Danube - Putting Task Estimates in Their Place - Comments

Capitalization

jschiel — Thu, 10 Jul 2008 08:46:51 -0500

P.Parker, thanks for your feedback.

When I started posting a reply, it got quite long. So, I made it a new blog entry and posted it here.

Great Article

pparker — Wed, 25 Jun 2008 08:06:46 -0500

The recent teams I've worked with get wrapped up in hours estimated for each Sprint, over analysis can cause team paralysis. Management wants to ensure each person on the team is at full capacity during a Sprint and want the estimates to match hours available. Unfortunately, it is a reality in most organization that projects are capitalized and the hours spent working on task need to be captured for business reasons. Therefore, they look at the initial estimates as gospel (i.e. in the Waterfall tradition). Until a development organization can show true benefits from loosely coupling task hours and capacity will this problem be resolved.

P.Parker

Ajayaram, I certainly

Jim Schiel — Mon, 16 Jun 2008 17:08:33 -0500

Ajayaram, I certainly wouldn't argue that there's never a benefit of tracking actuals in certain instances. As a Six Sigma Green Belt, I could definitely see the possibility for opportunitites in understanding where the team is spending too much time.

And don't get me wrong -- I'm not arguing against tasks in the Sprint Backlog -- that would be quite an obscure approach indeed. No, instead I'm simply suggesting that I've never, in 24 years, seen much opportunity in tracking actuals. Usually the circumstances from one "similar" task to another is so varied that it is quite difficult to isolate enough of the circumstantial effects to actually compare tasks.

Indeed, if improving team performance is a goal, may I recommend Sprint Retrospectives where the team is asked how and if they feel they are wasting or losing time on specific types of tasks of even if they are routinely forgetting types of tasks that they should remember during Sprint Planning or adding tasks during Sprint Planning that they really don't need. While I understand the possible use of task actuals in this scenario, I believe you'll find a in-depth retrospective much more efficient.

However you choose to proceed, good luck! I hope you get the same satisfaction from using Scrum as I've gotten over the past years.

Jim

ajayaram

MichaelJames — Mon, 09 Jun 2008 17:51:08 -0500

I've been programming since the CP/M-80 days, and still haven't gotten much better at estimating. I think this is true of all developers, but many are unwilling to admit this to themselves for fear of looking incompetent. (Similarly, we're also reluctant to admit we can't create a perfect architecture up front.)

The only thing I can remember getting good at estimating was creating entity EJBs, because I was using the same "cookie cutter" approach for each one. Then I realized I could make a generic doodad to reduce gruntwork, and the estimates got unpredictable (though smaller) again.

So maybe being too good at estimating something is a negative sign -- a clue we should have automated it already. The opportunities are at the edge of chaos, not in the repetitious work.

--mj

There are various reasons

ajayaram — Mon, 09 Jun 2008 11:56:49 -0500

There are various reasons for using tasks at the sprint level. Again it depends how the team uses to its benefit.
Adding tasks in a sprint helps team get a sense of whether the committed BIs in a sprint can be accomplished. This is also used as a communication between distributed teams.
I agree that actuals against estimate at the task level doesn't make sense overall from the sprint or release prespecitve. But for a team member who wants to get better at planning or increase efficiency by automation on a similar type of task can be beneficial.
I think there is some value to measure actuals against estimate at the points level. This is for the team to get better at estimating on similar kind of work. This should not be definitely used by management as a metric.
I have few more questions on tasks and its allocations based on the team dynamics but I will post it later.

Putting Task Estimates in Their Place

jschiel — Sat, 07 Jun 2008 08:20:37 -0500

Let’s look at how a team makes use of task estimates. During Sprint Planning, teams create tasks and task estimates from the backlog items that they are potentially going to commit to finishing.