19 ms·
My problem with project management tools is that they often become a brain dump of every possible little thing folks can think of - and over time, those things
by MattRogish 14y ago
My problem with project management tools is that they often become a brain dump of every possible little thing folks can think of - and over time, those things either happen to get done as a side effect of another story or become obsolete when market, product, or user needs change.
I like "high level" goals that can be prioritized ("User signup flow" is the most important thing we're working on this week, after that, it's probably "..."); the details for the high level stories can be done just-in-time.
My perfect PM feature for this is some sort of LRU expiry of stories. If someone hasn't opened a story (no views) or modified it within the last few months, move it to an archive. After a certain period of time in the archive, delete it.
Organizations and dev teams have a memory - if something is important, it'll be in the collective cache of the team. If something is relatively unimportant, it's waste (in the lean sense) to write it down until you have to (shortly before you need to prioritize and use it).
Bugs are the same thing. A bug is usually either worth fixing immediately (aka "next") or "never". Many bug trackers get clogged with stuff like "on IE7, the user dialog is 5 px to the right". It's either worth fixing right now or "never". Delete it, and if another user complains and it's recent enough that we remember the other story, then it bumps up the priority. But if it happens long after we all forgot it happened, it's still not important enough to fix.
This would go a long way to keeping the most important things at the top and avoiding the hell of "Did we have a story for that or something like 6 months ago?" associated searching. Both Pivotal and Trello have this sort of rosy picture of the world that folks will only be entering in "this is the most important thing we must do it this week" sort of stuff, which is unfortunately not how most project teams work. A more holistic PM tool would take into account user behavior and have a solution for this. Heck, something like HackerNews' front page algorithm would be pretty interesting applied to PM.
- flexterra 14y agoWe are on the same page here. One feature that we implement is the "non-sticky DOING state". Sorry for the name, we can't come up with anything for that one. The feature works like this. When you mark a tasks as DOING that state will only last for 24hrs. After that the "worker" will be notified that the "Blimp robot" removed the DOING state. The idea is to approach the problem you are talking about. Many times projects become filled with stuff that nobody works on. I know this is a very simplistic approach but it's a start. We have a few cards up our sleeves.
- MattRogish 14y agoWin x 1000! I will definitely give Blimp a try!
- andrewflnr 14y ago"temporarily in progress"? It does sound like a good idea.
- Spearchucker 14y agoI've a similar requirement in a dissimilar scenario. I'm an architect and work in an enterprise environment that's obsessed at the minute (to put it mildly) with Agile. A typical project will use Pivotal to capture requirements, track progress and manage changes. Project plans are non-existent, and a vague project schedule is done in Excel to convince the project sponsor to authorize the work. The result is big surprise all around when release one is unusable because the hipster tech doesn't integrate with Active Directory, the awesome server push engine doesn't resolve clients behind NAT, and a change to a business rule requires two weeks' refactoring. The team has talent, but they lack direction. What I need is something that a). captures high level requirements, b). does some basic risk management (plan, track, control) and c). does some stakeholder management so that the team knows whom in the organisation to ask about things like hosting.
- debacle 14y agoIt sounds like you need a project manager.
- Spearchucker 14y agoWe have one of those. She and the SCRUM master seem not to see things the same way. Mostly I'd butt in and mediate but this isn't strictly my project.
- debacle 14y agoSounds like you need a process management consultant, then.
- rhizome 14y agoI mean this in the most supportive way possible, but that place sounds like a nightmare. How's the turnover? P.S. Curious handle.
- Spearchucker 14y agoIt's a surprisingly awesome place to work. Everyone WANTS to be successful, do the right thing and have that awesome success story on their CV (resume). The problem here is more one from up high. The CIO has decided that GMail, the iPhone, SCRUM, Ruby, Zend and Mongo are where it's at, kindof bypassing the CTO who has to manage a legacy estate that operates on AD, Oracle, SQL Server, Java and .NET. Culturally it's really good - everyone seems to feel really empowered, they have real talent but it's a young team so they lack experience. I'm glad I work here. Spearchucker Jones is a character from M.A.S.H. The 1970 original is one of my all time favourites.
- mmanfrin 14y agoBugs are the same thing. A bug is usually either worth fixing immediately (aka "next") or "never". Many bug trackers get clogged with stuff like "on IE7, the user dialog is 5 px to the right". It's either worth fixing right now or "never". Delete it, and if another user complains and it's recent enough that we remember the other story, then it bumps up the priority. But if it happens long after we all forgot it happened, it's still not important enough to fix. I think this is only really acceptable if you are a very small team with very specific goals. I'm biased, as I work in QA, but these things are necessary because a lot of devs are pretty terrible at reading specs. QA will find scrolls of bugs, and having them all marked as 'next' is useless. You need things like priorities, you need things like Sprints.