Comment by bschmidt1

Comment by bschmidt1 12 hours ago

These guys were pioneers who set forth a lot of the patterns used in other PM software (Did they invent "Velocity"?). I hated Pivotal in the early days, but after a couple years on the job I learned to really love it especially as the newer flimsier sprint planning tools were popping up in the early web 2 days.

Only Trello really "beat it" fairly - Jira was always top-down forced, and Asana only won with designers because it was pretty while Pivotal was more tactical (not to mention they clung to skeuomorphic UI a little too long). The rest is history.

I guess we can say Pivotal was quite pivotal in the AGILE/sprint/PM software race. RIP

skybrian 11 hours ago

We were doing “velocity” at a startup using a rack of index cards. Software is not strictly necessary when everyone is in the same room.

Reply View 5 replies

latchkey 11 hours ago

PT's concept of velocity isn't just tracking a number. It is tracking what work will get done within a period of time based on the average amount of work done previously. It allowed PM's to actually estimate when a feature would be completed and how adding or removing stories (or people!) would impact future feature deadlines. Initial velocity was meaningless and only developed over time as an average value of a team of people working together, taking into account things like vacations and sick days. None of this could be done realtime with a rack of index cards as it was something that happened over many weeks.

Reply View | 4 replies
- twic 7 hours ago
  
  That concept of velocity is in the original Extreme Programming practice, which predates Pivotal, and it was indeed done with racks of index cards.
  It's explained pretty clearly in the first edition of Extreme Programming Explained, but i can't find a copy of that online right now. The second edition was absolutely ruined for some reason, but still contains a rough description of it:
  > Whichever units you use, hours or points, you will need to deal with the situation where actual results don't match the plan. [...] If you are estimating in points, modify the budget for subsequent cycles. A simple way to do this, dubbed "yesterday's weather" by Martin Fowler, is to plan in any given week for exactly as much work as you actually accomplished in the previous week.
  Tracker uses some kind of rolling average rather than just last week's number, but it's the same idea.
  
  Reply View | 1 reply
  
  latchkey 7 hours ago
  
  I never implied that PT invented the concept. I was just explaining the concept in relation to PT.
  Doing what PT does, with index cards, would have been a nightmare on any sufficiently large project.
  
  Reply View | 0 replies
- skybrian 9 hours ago
  
  Yes, that’s basically how we did it. Though not formally accounting for vacation days; there were four of us and we didn’t have people coming and going much. We only did it once a week during the retrospective. It’s not hard to add up story points for the week and remember what you did in previous weeks. You could enter it into a spreadsheet if you want to get fancy.
  The concept comes from Extreme Programming. Software implementations came later. I think Pivotal Tracker does something useful, but you need a larger team for it to matter.
  Here are some photographs of the team room:
  https://williampietri.com/writing/2004/teamroom/
  
  Reply View | 1 reply
  
  latchkey 7 hours ago
  
  > I think Pivotal Tracker does something useful, but you need a larger team for it to matter.
  My buddy and I built what ended up being an $80m/yr gross revenue business entirely using PT for ourselves. We shipped a MVP exactly to the week we predicted. It helped that we both worked at Pivotal and knew exactly how to use PT correctly.
  You certainly were early with the process and I applaud you for that! PT wasn't released until 2008.
  
  Reply View | 0 replies