5 ms·

Good to see our dislike of them validated, too. They don’t work well with sprints.

• gjvc 5y ago
  It's not validation, and your dislike is misplaced in the context of kevincox's comment: "But if those are big enough to need their own work I can't divide further to keep myself organized", where they are very much needed to track the work which needs to be done. The emergent behaviour of a jira installation seems to be one which more often serves management-by-ticket, not the "task progress" aspect of a lab notebook. GeePaw Hill's tweet is soberingly true https://twitter.com/geepawhill/status/1448667876907524108 https://twitter.com/geepawhill/status/1448667876907524108
  • ansgri 5y ago
    We worked around them by basically not using epics (using them to represent an endless line of work like Frontend, or Machine learning, the like), but instead introducing a new type of issue, Sprint goal, which is created by the team leads committee and linked to actual tasks as related issues by individual developers. So we have both ‘big picture’ for current work and not interfere with developers. The sprint goals serve to record current priorities agreed between teams and CTO, are 2 week-scoped (hopefully), and reviewed at the end of the sprint. Seems to work well for our ~50-developer department. edit: To add, overall Jira+Confluence is more pleasant to work with than Redmine and Basecamp, though it does require a big team with a couple part-time Jira experts to make it work.
• kevincox 5y ago
  > They don’t work well with sprints I think that was the "bug" in my context.
  • gjvc 5y ago
    now I'm confused as all hell, and I apologise for any offense caused.