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

The broader point with all this is every field comes up with jargon because it's a form of compression rather than repeating the same phrases again and again. The differences between what you've written there and how they've been used in the teams I've been in are the point here. Instead of saying "manhours but with a conversion factor that we figure out over time and an understanding of the variation" you say "story points".

Story points aren't hours. People are really bad at estimating with time, but they're much better if you just get them to compare things and say which one seems like it'll take longer.

Stories aren't tasks, either. A task is a single unit of work that you can do and complete. Stories are groups of things that solve a particular problem.

For example, adding a password reset is a story. But that might be distinct tasks that different people can take on, or should be coded and released independently. Maybe that requires setting up an email service or server, UI changes in the frontend, backend changes, is there design that needs doing for it, etc.

> Subtask = sprint

Sprint is a bit of a weird one sure but it's a short length of time. Different for different teams, typically 1-4 weeks.

> Upcoming tasks = backlog

Backlog isn't a very custom term here is it? Also it's not the upcoming tasks, it's things that probably should be done but not right now. New idea? New feature? Cool, backlog, doesn't interrupt the current set of work for the next couple of weeks.

Every field can do this with every other field. Doctors with their fancy words like anterior, why don't they just say "the bit at the front"?

I know there can be cringey project managers, yes. On the other hand, I've also seen highly skilled engineers scoff at these kinds of things then spend way too long building stuff that doesn't actually address what the user needs, misses out key parts because they never thought about who was actually tracking those ancillary pieces of work and making sure they're done, and fail to deliver.

Oh and finally if someone wants to come along and say "well we did it differently", if that worked for you then great! The classic point of agile was that you should try things and keep what works. None of these concepts are particularly complex imo.



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

Search: