4 ms·

> It turns into an exercise where the Notion document becomes the goal, rather than a tool to help get work done. Same, except it's Jira and Confluence. Everyt

• nuancebydefault 3y ago
  As long as you use Jira and Confluence to track what you are doing and make handy reference notes, they work super good. About showing burn down chats: usually they are shown a few times in early stages of the project, but don't get any attention anymore once they start showing unwanted or erratic results. Also story points estimations/tracking (as opposed to time in real world units) : never saw it work in practice. Whoever says software/hardware project time schedules are 'under control' or 'predictable' is probably joking.
  • Macha 3y ago
    I would argue that the performance of Jira being what it is along makes it pretty unsuitable for just taking reference notes. Our onprem hosted instance is pretty slow, which you might blame on server provisioning, except last time I used Jira cloud it was even worse with an empty instance (compared to our at least multiple million tickets instance)
    • nuancebydefault 3y ago
      Well Confluence is for the handy notes, which can grow into quality documents if you have them reviewed and updated. Personally never experienced performance issues.
  • majormajor 3y ago
    > About showing burn down chats: usually they are shown a few times in early stages of the project, but don't get any attention anymore once they start showing unwanted or erratic results. If your management can't understand these charts - including when you get results you don't want - I think your management is failing. E.g. if you don't realize "whoa there's a lot more ambiguity here than we expected and it's causing big delay" until the project goes sideways trying to find clarity, then you missed something big in your earlier planning and estimation. And whether or not it was important to spend the time to try to get a more accurate estimate vs just start building should be a business-requirement and project-specific decision, but it should be a conscious one.
• huehehue 3y ago
  > Everything has to have story points assigned to it just so we can say we did an arbitrary number of points per sprint If you have a manager that's treating N points as a target, then you just have a bad manager. Sprint points are just a signal for how over/under your estimates are on average, to help inform future planning. If someone goes on vacation, how do I know how much work the remaining team can handle? It's also a good signal for measuring the impact of team/process changes (to be clear, the idea here is post hoc analysis and not +N points as a target). That said, how would you prefer to handle capacity planning? Points aren't perfect, but trends should stabilize over time (you can have predictability/consistency without precision). You can even map point values to ranges of time (e.g. 1 point = [2, 8] hours) if it helps.
  • epolanski 3y ago
    I've never ever seen this estimation game lead to any better planning, ever.
    • huehehue 3y ago
      I can't think of any healthy team dynamic that doesn't require some form of deliverability estimates (this is not limited to engineering), and am very curious how you approach this.
      • epolanski 3y ago
        Ideally a good tech lead with a pulse of his team and stack should be able to do it alone. When estimations are crucial they can be further analyzed with more people. It's the beaurocratic gamification aspect I despise.
        • random_kris 3y ago
          Ideally a good tech lead should share stuff like that with the team to take into account opinions of team members. Having 2 meetings. 1 for task presentation and 1 for task estimation next day is really great