Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm not sure I agree with the framing of this article.

It seems to be comparing two different things, 1. Points as a method for attributing difficulty to a work item, vs 2. The collaboration process of creating a task list as a method of breaking down work.

Running a team, I found pointing useful, more useful than the individual line engineers did, as we had different goals. My goal, in optimizing the team, was to go through all our work, get everyone in a room and create a relatively optimal plan for the next couple of weeks.

By going through the exercise of pointing, we often found that something one person thought was hard, another found easy. That act of estimating would reveal knowledge one person had that another didn't, that made the task easier. Without that process, the work might have been harder do do, because the easy way was never revealed. We also adhered to a 8 points is too many philosophy that meant any item that hard needed to be decomposed to simple tasks to repoint.

The "queuing" section basically implies the planning process should decompose tasks all the way to nothing but 1 point stories (or at least similarly sized work items within some variance). It's basically the same process as pointing, except not calling out some things are chunkier than others because it all comes out in the wash.

TL;DR this articles definition of queuing is basically pointing where task = 1 point items.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: