6 ms·

Rough. PT's "automatic" sprint planning and velocity measurement has always been a killer feature for me as a solo user. Even if the free plan isn't going away

by wrl 3y ago

Rough. PT's "automatic" sprint planning and velocity measurement has always been a killer feature for me as a solo user. Even if the free plan isn't going away immediately, the writing's on the wall. Anybody know of other task/project management software that has similar automatic velocity measurement and sprint planning functionality? It does so much for my productivity that I might just build something myself if there's nothing else around.

geoelectric 3y ago
Yeah, if it doesn’t already exist this could be the forcing function. I know a lot of people like that functionality you describe.
namdnay 3y ago
Back in my enterprise days I remember getting decent results with the Portfolio add-on to JIRA. Like all things JIRA it’s a bit heavy and slow, but full of features
- throwway120385 3y ago
  They renamed it a few years ago, removed a bunch of features, and have been gradually re-adding them because they realized that Portfolio was only useful with those features. I'm still waiting for them to re-add features around capacity estimation by team member per project, a feature that was in Portfolio in 2017. At least they finally fixed the biggest issue I had with Portfolio, that the "save changes" view didn't have any filters.
esher 3y ago
Linear has something velocity like: https://linear.app/docs/project-graph https://linear.app/docs/project-graph - I am not using it and I don't know how it compares to PT.
- wrl 3y ago
  This is interesting but misses the real killer PT feature: closing the loop between velocity and planning: 1. Tasks have points 2. Sprints have duration 3. Points accomplished per sprint is velocity 4. Use the average velocity of the past few sprints to pull some number of tasks off the top of the backlog. Those are the tasks for the next sprint. It makes sprint planning basically transparent. I just prioritise the backlog (sometimes lazily) and it keeps me pretty productive. It's almost gamification in a way, but not quite.
  - oliviabenson 3y ago
    If you have a prioritised backlog and you’re working in priority order then there’s not much value in sprints — is there? Sprints provide value when you can’t just churn through tickets one after the other in priority order. Sprint planning is time consuming because sprints are useful when you need to plan. You could use Linear’s cycles and milestones but you probably don’t need any of that structure if you’re just working ticket by ticket.
    - latchkey 3y ago
      PT automatically adjusts the number of stories that make it into a sprint. They don't really have a concept of sprint actually... it is just average velocity over time and the number of stories that can fit into that average. If a PM wants to see how adding in just one more feature impacts the schedule, they can just drag the pointed story into the queue and see what gets pushed out to the next week. If a developer goes on vacation, it is easy to see how that impacts the schedule cause you can subtract their average velocity. Most people don't understand this killer feature of PT unless they've actually spent a bunch of time using it. It really enables you to do accurate project estimates, if you do it right. Source: worked for cloudfoundry/pivotallabs
    - rahoulb 3y ago
      I've not looked at Linear - but when I was freelancing I used Pivotal (free account) to just put all my clients' requests into one long queue (I had about 8 clients at any one time). I put in a very random guess as to the points value of each request - nothing more than "trivial, easy, difficult, bastard-bloody-hell-shit-buckets-difficult". I had Tracker set to work in "weekly sprints" - but they're not really sprints at all - it's just a unit of measure. Internally it averages the number of points completed over the last three weeks, uses that for an average velocity, then moves the date markers on the "backlog" list to match. Then, when a client asked when something will be done, I could pretty accurately say "unless something urgent crops up, it will be '18th-24th March'" (where "something urgent crops up" means I insert a story at the top of the queue instead of at the end).
nurettin 3y ago
I never liked their velocity diagram. I've had situations where I had great progress when it showed low, and I had situations when bugs and setbacks made the "velocity" measure meaningless. You can even inflate it with lots of "important" little tasks. It's just a bad metric to optimize for.
- robertlagrant 3y ago
  Almost all metrics are bad to optimise for. If you don't use it skillfully it won't work. Even if you do, it's a guide at best.

by wrl 3y ago

geoelectric 3y ago

Yeah, if it doesn’t already exist this could be the forcing function. I know a lot of people like that functionality you describe.

namdnay 3y ago

Back in my enterprise days I remember getting decent results with the Portfolio add-on to JIRA. Like all things JIRA it’s a bit heavy and slow, but full of features

throwway120385 3y ago
They renamed it a few years ago, removed a bunch of features, and have been gradually re-adding them because they realized that Portfolio was only useful with those features. I'm still waiting for them to re-add features around capacity estimation by team member per project, a feature that was in Portfolio in 2017. At least they finally fixed the biggest issue I had with Portfolio, that the "save changes" view didn't have any filters.

esher 3y ago

Linear has something velocity like: https://linear.app/docs/project-graph https://linear.app/docs/project-graph - I am not using it and I don't know how it compares to PT.

wrl 3y ago
This is interesting but misses the real killer PT feature: closing the loop between velocity and planning: 1. Tasks have points 2. Sprints have duration 3. Points accomplished per sprint is velocity 4. Use the average velocity of the past few sprints to pull some number of tasks off the top of the backlog. Those are the tasks for the next sprint. It makes sprint planning basically transparent. I just prioritise the backlog (sometimes lazily) and it keeps me pretty productive. It's almost gamification in a way, but not quite.
- oliviabenson 3y ago
  If you have a prioritised backlog and you’re working in priority order then there’s not much value in sprints — is there? Sprints provide value when you can’t just churn through tickets one after the other in priority order. Sprint planning is time consuming because sprints are useful when you need to plan. You could use Linear’s cycles and milestones but you probably don’t need any of that structure if you’re just working ticket by ticket.
  - latchkey 3y ago
    PT automatically adjusts the number of stories that make it into a sprint. They don't really have a concept of sprint actually... it is just average velocity over time and the number of stories that can fit into that average. If a PM wants to see how adding in just one more feature impacts the schedule, they can just drag the pointed story into the queue and see what gets pushed out to the next week. If a developer goes on vacation, it is easy to see how that impacts the schedule cause you can subtract their average velocity. Most people don't understand this killer feature of PT unless they've actually spent a bunch of time using it. It really enables you to do accurate project estimates, if you do it right. Source: worked for cloudfoundry/pivotallabs
  - rahoulb 3y ago
    I've not looked at Linear - but when I was freelancing I used Pivotal (free account) to just put all my clients' requests into one long queue (I had about 8 clients at any one time). I put in a very random guess as to the points value of each request - nothing more than "trivial, easy, difficult, bastard-bloody-hell-shit-buckets-difficult". I had Tracker set to work in "weekly sprints" - but they're not really sprints at all - it's just a unit of measure. Internally it averages the number of points completed over the last three weeks, uses that for an average velocity, then moves the date markers on the "backlog" list to match. Then, when a client asked when something will be done, I could pretty accurately say "unless something urgent crops up, it will be '18th-24th March'" (where "something urgent crops up" means I insert a story at the top of the queue instead of at the end).

nurettin 3y ago

I never liked their velocity diagram. I've had situations where I had great progress when it showed low, and I had situations when bugs and setbacks made the "velocity" measure meaningless. You can even inflate it with lots of "important" little tasks. It's just a bad metric to optimize for.

robertlagrant 3y ago
Almost all metrics are bad to optimise for. If you don't use it skillfully it won't work. Even if you do, it's a guide at best.