Ask HN: Why are software project management tools little more than todo lists?
I work with companies that use Linear. Fundamentally it’s a todo list. Why can’t we do better?
User stories/features don’t have a binary finished state. Equating them with tasks makes no sense.
Tools should build on user stories and requirements instead of tasks.
Stories should be organized into phases of planning, working, review.
Stories should be organized into releases, and be part of multiple releases.
User stories and releases should be separate things. A feature isn’t “done” when it’s shipped. The context around a feature should be kept across iterations.
Anybody else feel the same way? Thoughts?
2 comments
[ 3.1 ms ] story [ 16.2 ms ] threadI agree with some of your points. But, IMHO, user stories are not the best tool to describe a feature. Even Linear don't advocate on User Stories: https://linear.app/method/write-issues-not-user-stories
Either way, I see this as a build-your-own-workflow. Each company should try to find the best way to work. It's an iterative and empiric process.
The debate over user stories seems like one of semantics. Stories exist regardless of whether they are called "story". Requirements exist regardless of whether people get clarity and consensus on them before writing code.
Linear says don't write user stories, that they "obscure" the work that needs to be done. But clarifying use cases and requirements is the opposite of obscuring – it's specifying. They say that there's no need to articulate product requirements for common features like "todo lists". Who believes that? To-do lists can vary greatly in their functionality. I've worked with enough companies for long enough to know that people always have different ideas for how something is going to work, even for "simple" things.
Linear also says product discussions should be kept out of Linear. Fair enough. But then what is Linear really providing? Not much. Why use it?